何时使用数据库视图，何时不使用？答案

【问题标题】：When to use database views and when not?何时使用数据库视图，何时不使用？
【发布时间】：2010-10-12 10:13:48
【问题描述】：

这个问题是关于数据库视图，不是物化视图。

优点：

缺点：

还有什么？

【问题讨论】：

【解决方案1】：

优点：允许您更改底层数据结构而不影响应用程序正在使用的查询（只要您的视图可以隐藏数据结构）

【讨论】：

【解决方案2】：

安全。向应该能够查看从视图返回的列的用户授予对视图的访问权限。

【讨论】：

【解决方案3】：

当您不完全信任向您的数据库发送查询的一方时，视图非常棒。一个很好的例子是，您可以为承包商创建一个表格视图，以便他们可以看到与其项目相关的行。

【讨论】：

【解决方案4】：

虽然视图可以隐藏复杂性和多个连接，但这些复杂性本来就存在于 SP 中。

如果可以优化 SP，则应该优化视图，这将提高所有命中该视图的 SP 的性能。

视图非常强大和有用，其中一个原因比所有其他非常好的原因更突出。它们减少了代码重复。也就是说，在大多数情况下，底线。如果查询将在三个或更多地方使用，那么如果架构或查询参数发生更改，视图将大大简化您的更改。

我曾经不得不编辑 22 个存储过程来更改一些查询逻辑。如果原始架构使用视图，那么我将只有三个更改。

【讨论】：

【解决方案5】：

现在 SQL Server 拥有common table expressions，我发现自己创建的视图更少了。当我创建一个视图时，它通常是一个规范化的层次结构，可以在许多查询中使用，而不是替代一个查询。

例如 Region、Market 和 City 可能是三个标准化表（雪花）。我 90% 的查询都需要这些数据，所以我将创建一个视图。该视图永远不会替换单个查询，而是使所有其他查询变得简单和干燥。

【讨论】：

【解决方案6】：

我不得不多次使用视图来进行奇怪的连接和按别名分组。

通过奇怪的连接，我的意思是选择一个不同日期的列表，然后将它们外部连接到它们来自的表中，以获得空天的空条目。我想不出任何其他方法。

至于按别名分组，似乎取决于别名内公式的复杂程度。如果别名没有引用任何实际的列，或者已经被分组的列，那么一切正常，但是未包含在分组中的列上的别名会引发错误。

我似乎记得在我大学时代的某个地方读到或听到过，从视图中选择比从一堆连接的表中选择要快，但我不知道这是不是真的。

使用视图的最后一个优势：Excel 中的数据透视表。我认为没有加入表格的方法，或者至少在向导界面中没有。可能可以在 Microsoft Query 中进行联接，但我还没有尝试过，因为我现在才想到这个想法。

【讨论】：

【解决方案7】：

我以前一直使用它们，现在很少使用了。但是，我通过存储过程进行所有数据访问，因此视图的用处会有所降低，因为 SP 可以在需要的地方隐藏连接的复杂性。

如果 a 有许多表的特别复杂的连接，我仍然会考虑使用视图，然后我需要在其上构建许多 SP，但老实说，我想不出我有什么现在生产。

我会使用的另一种场景是我的用户可以访问数据库以生成他们自己的报告，我想为他们隐藏底层的复杂性。

【讨论】：

【解决方案8】：

视图比复杂查询更容易测试。当您想对 SQL 进行单元测试时，视图就是帮助。

【讨论】：