我只是想了解在RDBMSes中使用哪些视图的一般概念。也就是说，我知道一个观点是什么以及如何制定一个观点。我也知道我以前用过他们的东西。什么意见适合？
但我想确保我有一个什么样的看法是有用的一个透彻的了解，哪些视图不应该是很有用的。更具体地讲：
（并记录在案，其中有些问题是故意天真。这部分是一个概念检查。）
1）什么是有用的视图？
IOPO只在一个地方
•无论你考虑数据本身或引用连接表的查询，利用视图避免不必要的冗余。
•视图还提供了一个抽象层，防止直接访问表（以及由此产生的引用物理依赖关系的手铐）。事实上，我认为这是 好的做法 只提供抽象访问您的底层数据（使用视图和表值函数），包括视图如
CREATE VIEW AS
SELECT * FROM tblData
我hafta承认有一个很好的在这个建议中，“按照我说的做，不按我做的”）
2）有什么情况可以在你不应该使用视图的时候使用视图吗？
性能视图连接曾经是一个问题（例如SQL 2000）。我不是专家，但我一会儿不担心。 （我也不能想到我目前正在使用视图连接的位置。）
视图可能过度杀伤的另一种情况是只能从一个调用位置引用视图，而可以使用派生表。就像匿名类型优于.NET中的类一样，如果匿名类型只被使用/引用一次。
•见派生表描述 http://msdn.microsoft.com/en-us/library/ms177634.aspx
3）你为什么要代替使用的东西视象表值函数，反之亦然？
（除了性能原因）表值函数在功能上等同于参数化视图。实际上，一个常见的简单表值函数用例只是简单地将WHERE子句过滤器添加到单个对象中已存在的视图中。
4）有没有任何情况下，视图可能是有用的，乍一看并不明显？
我想不出任何不明显的用途。 （我想如果可以的话，那会使它们变得明显;）
在某种程度上，一个观点是一样的接口。您可以根据需要更改基础表结构，但该视图为代码提供了一种无需更改的方法。
视图是提供一些简单的报告作家的一个很好的方式。如果您的业务用户想要访问Crystal Reports等数据，则可以在他们的帐户中为其提供一些简化数据的视图 - 甚至可以为它们进行非规范化处理。
视图可以被用于提供安全性（即：用户可以访问的观点，仅访问在一个表中的某些列），视图可以为更新，插入等提供额外的安全视图还提供一种方法来别名柱名称（与sp相似），但视图更多地与实际表格隔离。
在某种意义上非规范化的意见。非规范化有时需要以更有意义的方式提供数据。无论如何，这是许多应用程序在其对象中通过域建模的方式。他们帮助以更贴近企业视角的方式呈现数据。
-1“views denormalize”？对不起，但这是无稽之谈，除非它是合格的。 – 2010-03-04 17:20:51
他们绝对非规范化。如果你有相关的表格被归一化为第三个统一形式，并且你创建了一个'扁平化'这个关系的视图，那么这不是非规范化？ – Kilhoffer 2010-03-05 13:34:26
视图可以集中或合并数据。我在哪里我们在几个不同的链接服务器上有许多不同的数据库。每个数据库保存不同应用程序的数据。这些数据库中的一些数据库保存了与许多不同应用程序相关的信息。在这些情况下，我们要做的是在应用程序的数据库中创建一个视图，从数据库中真正存储数据，以便我们编写的查询看起来不像跨越不同的数据库。
除了其他人声明的内容之外，视图还可以用于从应用程序中删除更多的复合SQL查询。
作为一个例子，而不是在应用程序操作的方式：
SQL = “选择A，B从表1工会 选择A，B从表2”;
你可以抽象的，要一个观点：
创建视图union_table1_table2_v为
选择A，B从表1
工会
选择A，B从表2
和在应用代码中，只需要：
sql =“select a，b from union_table1_table2_v”;
此外，如果数据结构有变化，您将不必更改应用程序代码，重新编译和重新部署。你只需要改变数据库中的视图。
为什么我要在数据库而不是应用程序中编写复杂的sql？ – 2012-06-09 06:33:36
查询越复杂，未来可能会发生更改，部分原因是由于它只会触及更多表格。当数据库结构发生变化时，您还必须更改代码并进行发布。如果在视图中抽象出这种复杂性，则DBA可能能够对下表进行结构更改，而无需更改代码。 – CodingWithSpike 2012-06-11 03:02:33
OP询问是否存在可能使用视图的诱惑，但这不合适。
你不想使用视图是复杂连接的替代。也就是说，不要让你的程序编程习惯将问题分解成更小的部分，这会导致你使用多个视图连接在一起而不是一个较大的连接。这样做会杀死数据库引擎的效率，因为它本质上是在做几个单独的查询而不是一个大的查询。
例如，假设您必须将表A，B，C和D连接在一起。您可能会试图从表格A & B以及从C & D以外的视图中查看视图，然后将这两个视图结合在一起。在一个查询中加入A，B，C和D会好得多。
我不认为这是正确的，至少这不是数据库管理系统理论的方式（各种实现可能决定不遵守该理论）。查询解析器将基本上用相应的sql替换它看到的任何视图，并且优化器将从那里开始。这两个案例应该是相同的。 – SquareCog 2008-10-18 00:03:19
当您可以将索引添加到视图时，这也不适用。 – therealhoff 2008-10-18 00:10:25
@Barry Brown：什么产品展示这种愚蠢的行为？ – 2010-03-04 17:26:39
答复迄今是正确的 - 观点有利于提供安全，非规范化（虽然有太多的痛苦下来，如果做错了这条道路），数据模型抽象等
此外，意见普遍用于实现业务逻辑（失效用户是在过去40天内未登录的用户，诸如此类）。
我想强调使用视图进行报告。通常，在规范化数据库表以提高性能（尤其是编辑和插入数据（OLTP使用））和反规范化以减少用于报告和分析（OLAP使用）的查询的表连接数量之间存在冲突。必要时，OLTP通常会赢，因为数据输入必须具有最佳性能。然后创建视图以获得最佳报告性能，可以帮助满足这两类用户（数据输入和报告查看者）。
视图隐藏了数据库的复杂性。他们出于很多原因很有用，并且在很多情况下都很有用，但如果您有允许用户编写自己的查询和报告的用户，则可以将它们用作安全措施，以确保他们不会提交设计不当的问题查询与令人讨厌的笛卡尔联接，取消您的数据库服务器。
视图可以在SQL脚本中保存大量重复的复杂JOIN语句。您可以在某个视图中封装一些复杂的JOIN，并在需要时在您的SELECT语句中调用它。这有时会比在每个查询中写出连接语句方便，直接和容易。
我记得一个很长的SELECT，它涉及几个UNION。每个UNION都包含一个加入价格表的功能，这个功能是通过一个SELECT自己创建的，本身相当长且很难理解。我认为创建价格表是一个好主意。它会将整个SELECT缩短一半左右。
我不知道数据库是否会评估一次或每次调用一次。有人知道吗？如果前者使用视图会提高性能。
视图只是一个存储的命名SELECT语句。考虑像库功能这样的观点。
无论何时您需要[my_interface]！= [user_interface]。
例子：
表A：
查看表A：
这是一种方法，您可以隐藏来自客户的id并将信息同时重命名为更详细的名称。
该视图将使用主键ID的基础索引，因此您不会看到性能损失，只是选择查询的更好的抽象。
类似于此处发布的问题：http://stackoverflow.com/questions/1278521/why-do-you-create-a-view-in-a-database – MedicineMan 2010-02-05 00:58:07