使用SQL View或SQL Query？

Question

我正在开发一个从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比较复杂.

Answer 1

我会出于几个原因创建一个VIEW

A)构造良好的视图确实比查询执行速度更快,但是通过查询优化,您可能不会发现很多差异.

B)它保持数据库结构内部数据库结构的知识 - 添加一个良好的抽象层(作为旁注,考虑使用存储过程而不是内联查询 - 这也使数据库知识保持在数据库本身内)

C)如果确实需要对数据库进行结构更改,则可以保持视图的一致性,而无需重新构建代码.

修正案我将根据一些意见修改这个答案,以澄清一些观点......

毫无疑问,标准视图不会在查询中提供任何实际的性能提升.标准视图在运行时实现,这实际上使它与执行相同结构的查询的便捷方式没有区别.但是,索引视图会立即生效,结果将保留在物理存储中.与任何设计决策一样,应仔细考虑使用索引视图.天下没有免费的午餐; 您为使用索引视图而支付的代价是以额外的存储要求和与基础数据库发生任何更改时维护视图相关的开销的形式出现.这些最适用于常用的复杂连接和多个表中数据聚合的情况,以及访问数据的频率远远超过更改的情况.

我也同意有关结构变化的评论 - 添加新列不会影响视图.但是,如果数据被移动,规范化,存档等,则可以将这些更改与应用程序隔离开来.这些情况是RARE,通过使用存储过程而不是视图可以获得相同的结果.