- Indexed Views：通过在视图上创建聚集索引将视图物化，通常用来提高查询性能，复杂的Join和聚合函数都被提前计算出来，避免在查询执行这些操作，以此来提高性能
- Views通常用来聚集Focus、简化、定制用户对数据库的视角，其优点包括：
- 允许用户集中在和他们相关或者允许他们操作的那一小块数据上
- 隐藏了查询的复杂性，用户不需要关心视图中涉及的复杂查询，他们可以像表一样操作视图
- 简化用户许可管理，即提供一种安全机制，只允许用户通过视图访问数据，不允许用户直接操作底层表
- 为应用程序提供导出的数据，许多应用程序没有权限执行存储过程或者T-SQL代码，只可以查询数据，视图将应用程序需要导出的数据独立出来
- 提供向后兼容性，比如Customer表被拆分成CustomerGeneral和CustomerCredit两张表，为了保持向后兼容，可以创建Customer视图，这样应用程序原来的查询就不需要修改
- 为报表应用程序提供结构化数据，报表应用程序需要执行复杂的查询，视图可以用来为这些应用程序提供数据，这样就不需要将复杂的查询逻辑嵌套到应用程序中
- 创建视图时如果指定了WITH SCHEMABINDING，底层表如果影响视图定义的话，不可以修改，如果你想Index视图的话，必须指定这个选项；视图可以基于其他视图创建，但是嵌套最多不能超过32层，对于嵌套很深的视图都要很谨慎，因为这样的视图对于理解和问题调试都增加了复杂度；视图中的查询通常都是无序的，除非遇到像TOP这样的语句时才使用Order By；查询中返回的表达式需要起别名，也可以在创建视图时，在视图名称后面添加Column列表，类似于：Create View TestView(Column1,Column2)
- 删除视图，视图相关的Permission也会被删除，当重新创建视图时，这些Permission不会恢复；修改视图则不会删除这些Permission，而且代码也比删除重建简单，Indexed Views也可以修改
- 当查询视图时，从视图到底层表的ownership链必须是不中断的，除非执行查询的用户也拥有底层表权限，比如：Nupur创建了视图，访问Tim拥有的表中的数据，然后授权John可以访问刚刚创建的视图，那么Join是不能使用这个视图的，即使Nupur可以访问Tim拥有的表中的数据，也就是说ownership链是中断的，但是如果Tim向John开放了表的权限的话，John就可以使用创建的视图啦
- 在引入Schema概念以后，对象依然是有owner的，引入Schema后，只是简化了安全配置，即Schema的owner也用于Schema中包含的对象
- 查看视图源信息的一些方式：SSMS，sys.views系统视图，Object_DEFINITION()函数；查看关于对象的依赖：sys.sql_expression_dependencies视图；查看列级别依赖：sys.dm_sql_referenced_entities视图
- 视图更新：
- 视图是不维护数据的
- 更新视图其实就是更新底层表中的数据
- 创建视图可以为视图指定WITH CHECK OPTION选项，该选项作用如下：更新视图中的行可能将属于视图的行更新后不再属于该视图，如果不指定该选项，这些行就不再属于该视图，指定该选项后，就不再允许这样的更新
- 更新视图的限制：
- 不能更新通过函数或者表达式生成的列
- 不能更新涉及到分组操作的列（比如GROUP BY，HAVING，DISTINCT）
- 通过视图更新底层表中的数据时，也必须满足底层表中定义的约束
- 可以通过指定WITH ENCRYPTION语句对视图定义进行混淆，这样的加密不是非常强，许多第三方工具都可以破解
- 当查询视图时只生成一个查询计划，不会为视图生成单独的查询计划，视图也不会出现在查询计划中，查询计划中只会看到底层表；将视图查询和外部查询进行合称为内联查询，这对于提高性能非常有好处，因为消除了不必要的连接和表访问
- 在创建视图时避免使用SELECT *，因为如果你向底层表新添加一列后，视图是不会反应出这个变化的，必须使用Alter View语句或者sp_refreshview系统存储过程才能刷新视图
- local partitioned view本地分区视图就是指所有分区表和分区视图都在同一个SQL Server实例上，大多数情况下都使用表分区替代本地分区视图；distributed partitioned view分布式分区视图是指至少一个分区表在另外一个不同的服务器上，分布式分区视图用来实现数据库服务器联合体；分区视图需要严格的计划和测试，否则会出现严重的性能问题
|
