使用视图编写查询是一个好策略吗？

Question

我只想知道是否通过首先在视图中创建查询来编写查询是否正确。

有什么建议吗？

Answer 1

查询视图通常是可以的，因为sql服务器优化器不容易上当。但是不要在你的视图中使用标量函数，否则你会遇到性能问题。

Answer 2

这取决于你在视图中做什么，以及你打算如何处理它们。

创建视图，然后将它们层叠在一起（通过引用另一个视图中的视图）通常不是一个好主意。在视图中使用ORDER BY也是一个普遍的否定，因为如果你加入视图 - 按顺序执行，但不需要它。

Answer 3

视图是一个宏，并且是expanded。

视图之上的视图仅仅意味着更多的工作让优化器解开下面的复杂性。

Answer 4

在一天结束时，视图只是一个子查询，所以它真的没什么大不了的。

SELECT * 
FROM (
    SELECT * 
    FROM myTable 
    WHERE a = 2 
) a 

无异于是

SELECT * 
FROM myView 

该计划被缓存，因此你真的不遭受任何性能影响，你会得到重用你的代码是其他的灵活性。

Answer 5

我知道有一个school of thought表示你应该有一个每张表的视图，并根据你的视图而不是你的表开发你的代码。在这种情况下，您可以使用演化开发方法，并且在修改表格时为新代码开发新视图，而不会破坏旧代码依赖的视图。我从来没有真正有过一个我认为会很复杂的项目，所以我不能随着表格的更改而更新代码，所以我从来没有使用过这种方法。

至于写入查询视图有一种情况下，我这样做。但是，它们可能是特定于我使用LINQ的，因此请带上一点盐。如果我有一个查询需要一些复杂的处理并返回一个基于多个表的复合对象，我通常会编写一个存储过程或表值函数来执行查询。我发现使用LINQ设计器最简单，如果我还创建了一个视图，我可以拖放到设计界面上为sp /函数返回的对象创建类，而不是让它自动生成类。如果我选择的话，它给了我更多的对命名类的控制权。