5

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

谢谢

4

7 回答 7

7

这不能真正客观地回答，因为它取决于具体情况。

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

这有几个好处：

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

但也有一定的缺点：

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

如果您坚持SQL92 标准，这是一个很好的折衷方案。

我的 2 美分。

于 2012-06-13T14:56:45.330 回答
1

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

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

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

对于 Views 的直接观点，使用它们的优点包括：

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

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

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

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

于 2012-06-13T14:56:46.140 回答
0

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

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

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

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

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

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

于 2012-06-13T14:51:40.603 回答
0

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

于 2012-06-13T14:51:48.847 回答
0

您所说的技术称为非规范化。Flickr 的软件工程师 Cal Henderson 公开支持这项技术。

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

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

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

于 2012-06-13T15:08:28.793 回答
0

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

于 2012-06-13T14:50:33.870 回答