最佳实践：sql 视图真的值得吗？ [复制]

Posted 2023-02-26

【中文标题】最佳实践：sql 视图真的值得吗？ [复制]

【英文标题】：Best practises : is sql views really worth it? [duplicate]

【发布时间】：2012-06-13 14:47:45

【问题描述】：

我正在使用存储在数据库中的数据构建一个新的 Web 应用程序。与许多 Web 应用程序一样，我需要从复杂的 sql 查询中公开数据（使用多个表中的条件进行查询）。我想知道在数据库中将我的查询构建为 sql 视图而不是在应用程序中构建它是否是一个好主意？我的意思是这样做有什么好处？数据库性能？我会写更长的代码吗？调试时间更长？

谢谢

【问题讨论】：

注意事项...我们有一个古老的观点，已经成为整个网站的事实上的标准，它被用于许多地方，就像一张桌子一样。该视图对许多字段进行了排序，然后在其他地方使用它也对结果进行了排序......很好而且很慢

【参考方案1】：

这个问题无法真正客观地回答，因为这取决于具体情况。

通过视图、函数、触发器和存储过程，您可以将应用程序的部分逻辑移动到数据库层。

这有几个好处：

性能 - 您可以避免数据往返，并且使用所有 DBMS 功能可以更有效地处理某些处理。 一致性 - 使用 DBMS 功能可以更轻松地表达某些数据处理。

但也有一定的缺点：

可移植性 - 您越依赖 DBMS 的特定功能，应用程序的可移植性就越差。 可维护性——逻辑分散在两种不同的技术中，这意味着维护需要更多的技能，并且本地推理更难。

如果您坚持使用SQL92 standard，这是一个很好的权衡。

我的 2 美分。

【参考方案2】：

我认为您的问题在您想要实现的目标方面有点令人困惑（获得有关 SQL 视图或如何构建应用程序的知识）。

我相信所有数据库逻辑都应该存储在数据库层，最好是存储在存储过程中，而不是存储在应用程序逻辑中。然后应用程序逻辑应该连接到数据库并从这些过程/函数中检索数据，然后在您的应用程序中公开这些数据。

将其存储在数据库层的好处之一是通过 SQL Server 来利用执行计划（您可能无法通过应用程序逻辑直接访问它）。另一个优点是您可以分离应用程序，即如果需要更改数据库，您不必直接修改应用程序。

对于视图的直接点，使用它们的优点包括：

将用户限制为表中的特定行。 例如，允许员工在劳动力跟踪表中仅查看记录其工作的行。

将用户限制为特定列。 例如，允许不在工资单中工作的员工查看员工表中的姓名、办公室、工作电话和部门列，但不允许他们查看任何包含工资信息或个人信息的列。

连接多个表中的列，使它们看起来像一个表。

http://msdn.microsoft.com/en-us/library/aa214068(v=sql.80).aspx

【参考方案3】：

我个人更喜欢视图，尤其是对于报告/应用程序，因为如果数据中存在任何问题，您只需更新单个视图，而不是重新构建应用程序或手动编辑查询。

【参考方案4】：

SQL 视图有很多用途。尝试先阅读它们，然后问一个更具体的问题：

http://odetocode.com/code/299.aspx http://msdn.microsoft.com/en-us/library/ms187956.aspx

【讨论】：

我认为问题的基本点已经足够具体，只是措辞不是特别好。

【参考方案5】：

我看到视图被大量用于做两件事：

简化查询，如果您有一个包含多个连接和连接和连接的 HUGE 选择，您可以创建一个性能相同但查询只有几行的视图。 出于安全原因，如果您有一个表包含一些不应被所有开发人员访问的信息，您可以创建视图并授予查看视图而不是主表的权限，即： table 1: Name, Last_name, User_ID, credit_card, social_security。你创建一个视图表。table view: name, last_name, user_id。

【参考方案6】：

您可能会遇到性能问题和可以针对视图运行的类型查询的限制。

限制您可以对视图执行的操作。

http://dev.mysql.com/doc/refman/5.6/en/view-restrictions.html 看起来最大的问题是您无法在视图上创建索引。如果您的最终结果表很大，这可能会对性能造成很大影响 这也是一个讨论观点的好论坛：http://forums.mysql.com/read.php?100,22967,22967#msg-22967

根据我的经验，一个索引良好的表、使用正确的引擎并经过适当调整（例如设置适当的 key_buffer 值）可以比视图执行得更好。

或者，您可以创建一个触发器，根据其他表的结果更新一个表。 http://dev.mysql.com/doc/refman/5.6/en/triggers.html

【参考方案7】：

你说的技术叫denormalization。 Flickr 的软件工程师 Cal Henderson 公开支持这项技术。

理论上JOIN 操作是最昂贵的操作之一，因此非规范化 是一个很好的做法，因为您正在使用 转换n 个查询m JOIN 在 1 个查询中，m JOIN 和 n 从视图中选择的查询。

也就是说，最好的方法是自己测试它。因为对 Flickr 可能非常好的东西可能对您的应用程序没有那么好。

此外，从一个 RBDMS 到另一个，视图的性能可能会有很大差异。例如，根据 RBDMS 视图可以在原始表更改时更新，可以有索引等。