2

编写视图时 - 我应该坚持使用基表还是我可以确信在视图中包含视图不会损害性能。我想包含该视图,因为如果我对表设计进行更改而不是更新依赖于已更改表的每个视图,它将允许我更改一个基本视图。这似乎是更明智的做法,但要确保我没有做被认为是不好的做法或损害性能的事情。

4

2 回答 2

3

在 SQL Server 中,视图在编译时得到解析。编译期间对性能的影响非常小。对实际查询执行没有影响。然而,这假设将选择相同的计划。如果嵌套包含复杂连接的视图,您可能会遇到访问表的频率超出必要的情况。优化器无法解决这个问题,系统最终会做很多不必要的工作。因此,请注意仅将视图放入不包含比通过编写没有视图的查询所访问的更多表的查询中。

于 2012-10-28T21:19:34.883 回答
1

从历史上看,一些平台在优化包含多个级别视图的查询时遇到了“麻烦”。我说“麻烦”,因为大多数时候即使是优化不佳的查询对我来说也足够快。(几乎一直都是。但我尽量不要生活在最前沿。)

几年前,我决定在有意义的时候使用视图。用心使用视图可以大大简化复杂的数据库;我们知道。但我决定相信优化器会做得足够好,并相信开发人员会在我的查询埋没服务器之前发布升级,使优化器变得更好。

因此,如果我认为视图可以减轻我的精神负担我就创建了一个视图。如果我需要查询视图的视图,我只是这样做了。

到目前为止,事实证明,这个决定对我来说是一个很好的决定。我从来没有用查询杀死过服务器,我仍然理解我的表和视图。(不过,在将查询转移到生产环境之前,我仍然会查看执行计划并测试性能。)

于 2012-10-29T11:19:55.227 回答