使用SQL View或SQL Query？
我正在开发一个从MS-SQL服务器获取数据的应用程序（2005）。 在命令文本中，我可以像这样传递一个sql查询：
string query = "SELECT T1.f1, T1.f2, T2.f3 FROM table1 T1 join table2 T2" + "on T1.id = T2.id AND T1.dt = T2.dt ..." .... cmd.CommandText = query; 我也可以将查询作为我的SQL服务器上的视图，如下所示：
CREATE VIEW V1 AS "SELECT T1.f1, ..."
然后我可以在这样的简化查询中使用视图：
string query = "SELECT f1, f2, f3 FROM V1"; .... cmd.CommandText = query;
我不确定哪条路更好。 视图会比SQL查询更快吗？ 顺便说一下，我在这里展示的查询是一个简化的查询。 实际查询SELECT比较复杂。
我会出于几个原因创建一个VIEW
A）构造良好的视图确实比查询执行速度更快，但是通过查询优化，您可能不会注意到很多差异。
B）它保持数据库结构内部数据库结构的知识 – 添加一个良好的抽象层（作为旁注，考虑使用存储过程而不是内联查询 – 这也将数据库知识保存在数据库本身内）
C）如果确实需要对数据库进行结构更改，则可以保持视图的一致性，而无需重新构建代码。
修正案我将根据一些意见修改这个答案，以澄清一些观点……
毫无疑问，标准视图不会在查询中提供任何实际的性能提升。 标准视图在运行时实现，这实际上与执行相同结构的查询的便捷方式没有区别。 但是，索引视图会立即生效，结果将保留在物理存储中。 与任何设计决策一样，应仔细考虑使用索引视图。 天下没有免费的午餐; 您为使用索引视图而支付的代价是以额外的存储要求和与基础数据库发生任何更改时维护视图相关的开销的forms出现。 这些最适用于常用的复杂连接和多个表中数据聚合的情况，以及访问数据的频率远高于更改的情况。
我也同意有关结构更改的评论 – 添加新列不会影响视图。 但是，如果数据被移动，规范化，存档等，则可以将这些更改与应用程序隔离开来。 这些情况是RARE，通过使用存储过程而不是视图可以获得相同的结果。
一般来说，我发现最好使用视图有几个原因：
- 复杂的查询很难在代码中读取
- 您可以在不重新编译的情况下更改视图
- 与此相关，只要返回相同的字段，您就可以处理视图中底层数据库结构的更改，而不会触及代码
可能有更多的原因，但此时我永远不会直接在代码中编写查询。
您还应该研究某种ORM（对象关系映射器）技术，如LINQ to SQL（L2S）。 它允许您在代码中使用类似SQL的查询，但所有内容都通过在L2S设计器中创建的对象进行抽象。
（实际上，我实际上正在移动我们当前的L2S对象来运行视图。它有点复杂，因为关系也没有通过……但它允许我创建一组遍历2的对象数据库，并保持一切很好的抽象，所以我可以更改基础表名称来修复命名约定。）
或者您可以使用存储过程。 使用存储过程将允许SQL缓存执行计划。 我认为一个观点也是如此。 您的第一种方法（即席查询）可能效率最低。
没有性能差异（除非sql查询的文本真的很大并且在线路上产生成本）。
视图可能更快，因为您正在请求更短的命令字符串，但差异将是无关紧要的。
Views的真正区别和价值在于，它们与函数和子例程一样，是可重用的 。
视图不是性能特征。 它们的存在是为了减少连接数，并允许您在不实际非规范化的情况下进行非规范化。
换句话说，除非你有充分的理由，否则请使用最简单的代码，不要因为性能原因而改变。 这些优化通常不值得。
视图可能更好。
这样，您可以在以后修改查询（用于优化），而无需更改代码。
对我而言，视图的优点是您可以为它们应用安全上下文。 或者在极端情况下，出于性能原因，您可以使用分布式分区视图。 否则他们会复杂化版本。 您现在必须确保部署了正确的视图版本以及数据访问dll的新版本。
我曾经认为存储过程是可行的，因为它们是a）编译（更快）和b）安全边界。 在现实世界中，这通常是不成熟的优化。 从客户端发送的SQL命令文本通常足够（并且更容易进行版本和部署），并且在许多情况下，表级别甚至整个数据库的访问控制都是足够的。
除非你在第2段中符合个人资料，否则我建议远离观点。 它们具有欺骗性的诱惑作为抽象底层function的好方法。 但问题是，一旦开发人员开始创建视图，他们就会开始为每个可能的表和字段组合创建不同的视图，并最终导致一个不协调的爆炸性混乱。 然后DBA必须维护所有这些，因为没有办法告诉哪些实际使用，哪些不是，开发人员最终只是编写自己的连接，因为它比浏览和确定哪个现有视图更容易使用。
IMO，使用视图（以及相当常见的视图）的唯一理由是DBA是否需要自由修改基础表而不破坏现有客户端代码。 如果逻辑在视图或proc中的DB端，这显然是唯一可能的。 如果这适用于您，请继续使用视图。 否则，我建议采用不同的方式来看待事物。
视图的力量是它创造的抽象。 但事实是，抽象仅由客户端使用，而不是由DB本身使用。 因此，我发现将抽象放在客户端更好。 因此，只需在客户端代码中的某个位置定义一个宏或字符串生成器，而不是视图，它将为您创建select语句。 随着您的应用程序的进展，您可以使这些变得简单并且逐渐变得更加复杂。 这样，您可以保持视图提供的abstration和可重用性，但避免视图爆炸和开发人员 – DBA通信瓶颈。