使用SQL视图还是SQL查询？

我正在研究从MS-SQL服务器获取数据的应用程序（2005）。在命令文本，我可以通过一个SQL查询是这样的：使用SQL视图还是SQL查询？

string query = "SELECT T1.f1, T1.f2, T2.f3 FROM table1 T1 join table2 T2" + 
    "on T1.id = T2.id AND T1.dt = T2.dt ..." 
.... 
cmd.CommandText = query;

我也可以把查询作为视图我的SQL服务器上是这样的：

CREATE VIEW V1 AS 
    "SELECT T1.f1, ..."

然后我可以使用视图在这样的简化查询中：

string query = "SELECT f1, f2, f3 FROM V1"; 
.... 
cmd.CommandText = query;

我不确定哪种方式更好。将视图更快，然后SQL查询？顺便说一下，我在这里展示的查询是一个简化的查询。实际的查询SELECT比较复杂。

来源

2009-06-17 David.Chu.ca

我会创造有以下几个原因

A）构建良好的观点并倾向于执行比查询速度更快，但优化查询，你可能不会注意到多大的差别的视图。 B）它保持数据库本身的数据库结构知识 - 添加一个好的抽象层（作为附注，考虑使用存储过程而不是内联查询 - 这也可以将数据库知识保存在数据库本身中）

C）如果您确实需要对数据库进行结构更改，则可以保持视图一致而无需重新编译代码。

修订我要修改这个答案中的一些评论的光，以澄清一些点...

这是绝对的事实标准视图不提供任何实际的性能增益通过查询。标准视图在运行时被实现，这基本上使得它与执行相同结构的查询的便利方式没有区别。但是，索引视图会立即实现，并且结果将保留在物理存储中。与任何设计决定一样，应仔细考虑使用索引视图。天下没有免费的午餐;您使用索引视图所付出的代价是以附加存储需求和与底层数据库发生任何更改时维护视图相关的开销的形式出现的。这些最适用于常用的复杂连接和多个表中数据聚合的情况，以及数据访问频率比更改频率更高的情况。

我也同意有关结构变化的意见 - 添加新列不会影响视图。但是，如果数据被移动，标准化，归档等，它可能是将这些变化与应用程序隔离的好方法。这些情况是RARE，通过使用存储过程而不是视图可以获得相同的结果。

来源

2009-06-17 03:38:53

不利的一面是您必须与客户端代码同步部署和版本化您的视图。 – 2009-06-17 03:50:16

或者你可以使用存储过程。使用存储的proc将允许SQL缓存执行计划。我认为一种观点也是如此。您的第一种方法（即席查询）可能效率最低。

来源

2009-06-17 03:36:17 Fantius

该视图可能更好。

这样，您可以在以后修改查询（用于优化）而无需更改代码。

来源

2009-06-17 03:36:20 Josiah

实际上查询将被设置在配置文件中，因此可以在不重新编译代码的情况下更改它。 – 2009-06-17 03:40:18

可能比重新编译更贴切的问题会让未来的开发人员很容易找到。视图存储在数据库中，对于那些有权访问SQL服务器的人来说是清晰可见的。隐藏在配置文件中的查询可能很难找到。 – Josiah 2009-06-17 04:15:50

查看可能会更快，因为您请求的是较短的命令字符串，但区别将是不重要的。

Views的真正区别和价值在于，就像功能和子程序一样，它们是可重复使用的。

来源

2009-06-17 03:36:37 RBarryYoung

没有性能差异（除非sql查询的文本确实是巨大的并且导致电线成本）。

来源

2009-06-17 03:37:36

总的来说，我发现这是最好用的观点有以下几个原因：

复杂查询可以得到硬代码阅读
您可以更改视图，而无需重新编译
与此相关的，只要返回相同的字段，就可以在视图中处理底层数据库结构中的更改，而不会触及代码。

可能还有更多的原因，但在这一点我绝不会直接在代码中编写查询。

您还应该研究一些类似于LINQ to SQL（L2S）的ORM（对象关系映射器）技术。它可以让你在你的代码中使用类似于SQL的查询，但是通过在L2S设计器中创建的对象来抽象所有东西。（实际上，我实际上将我们当前的L2S对象移动到视图的外面，这更复杂一点，因为关系并没有通过，但它允许我创建一组对象它可以跨2个数据库运行，并且保持抽象的一切都很好，所以我可以更改基础表名来修复命名约定。）

来源

2009-06-17 03:40:48 CodeRedick

对我来说，视图的优点是可以将安全上下文应用于它们。或者在极端情况下，出于性能考虑，您可以使用分布式分区视图。否则，他们会复杂版本控制。您现在必须确保部署正确版本的视图以及数据访问DLL的新版本。

我曾经争辩说存储过程是要走的路，因为它们是a）编译（更快）和b）安全边界。在现实世界中，这往往是不成熟的优化。从客户端发送的SQL命令文本通常具有足够的格式（以及更易于版本化和部署），并且在表级别甚至整个数据库的访问控制在许多情况下都是足够的。

来源

2009-06-17 03:55:53

视图不是性能特征。它们的存在是为了减少连接的数量，并允许你在不实际反规范化的情况下进行非规范化。

换句话说，使用哪一个让你的代码最简单，不要因性能原因而改变，除非你有好理由这样做。这些优化通常不值得。

来源

2009-06-17 04:22:59

除非您符合第二段的内容，否则我建议您远离观点。它们看似诱人，是抽象出底层功能的好方法。但问题是，一旦开发人员开始创建视图，他们往往会开始为表和字段的每种可能的组合创建不同的视图，并最终导致不协调的爆炸性混乱。然后，DBA必须维护所有这些数据库，因为无法分辨哪些数据库被实际使用，哪些不是，开发人员最终只是自己编写自己的连接，因为它比浏览和查明哪个现有视图更容易使用。

IMO，使用视图（以及相当常见的一个）的唯一好理由是如果DBA需要自由修改基础表而不破坏现有的客户端代码。这显然只有在逻辑位于视图或过程的数据库端时才有可能。如果这适用于您，请继续并使用视图。否则，我会推荐一种看待事物的不同方式。

视图的力量是它创建的抽象。但事实是，抽象仅由客户端使用，而不是由数据库本身使用。因此，我觉得把这种抽象放在客户端上会更好。因此，而不是视图，只需在客户端代码的某处定义一个宏或字符串生成器，它将为您创建您的select语句。开始时可以使这些变得简单，并随着应用程序的进展逐渐变得更加复杂。通过这种方式，您可以保持视图所提供的可弃用性和可重用性，但避免视图爆炸和开发人员与DBA之间的通信瓶颈。

来源

2009-09-09 21:20:07

使用SQL视图还是SQL查询？

回答

相关问题