构成视图时 - 我应该坚持使用基本表，还是可以确信，在视图中包括视图不会损害性能。我想包含视图，因为如果我对表面设计更改而不是更新依赖于表更改的每个视图的表设计，它将允许我更改一个基本视图。这似乎是更聪明的事情，但要确保我没有做一些被认为是不良练习或伤害性能的事情。
在SQL Server视图中，在编译时可以解决。编辑期间的性能影响很小。对实际查询执行没有影响。但是，假设将选择相同的计划。如果您嵌套包含复杂连接的视图，则可能会遇到比必要的频率更频繁地访问表的情况。优化器将无法弄清楚这一点，并且系统最终将做更多的工作。因此，请小心仅将视图放入不包含表格的查询的查询中，而不是您在没有视图的情况下访问查询。
历史上，有些平台遇到了"麻烦"优化包含多个视图的查询。我说"麻烦"，因为当时大多数即使优化较差的查询也足够快。（几乎一直都是。但是我尽量不要生活在出血边缘附近。）
几年前，我决定在有意义的情况下使用视图。周到的视图使用可以极大地简化复杂的数据库；我们都知道这一点。但是我决定相信优化器可以做一个足够好的工作，并相信开发人员可以释放升级，从而在我的查询掩埋服务器之前使优化器更好。
因此，如果我认为视图会减少 me 的心理负担，我会创建一个视图。如果我需要查询视图的视图，那就做到了。
到目前为止，这一决定对我来说是一个不错的决定。我从来没有用查询杀死服务器，但我仍然了解我的桌子和视图。（但是，在将查询转移到生产之前，我仍然要研究执行计划和测试性能。）