最佳实践:sql视图真的值得吗?

时间:2012-06-13 14:47:46

标签: mysql sql sql-server

我正在使用存储在数据库中的数据构建新的Web应用程序。尽可能多的Web应用程序,我需要从复杂的SQL查询中公开数据(从多个表中查询条件)。我想知道在数据库中构建我的查询作为sql视图而不是在应用程序中构建它是否是一个好主意?我的意思是什么会有什么好处?数据库性能?我会更长时间编码吗?调试时间更长?

谢谢

7 个答案:

答案 0 :(得分:5)

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

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

这可以有几个好处

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

但也有某些缺点

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

如果坚持SQL92 standard,那么这是一个很好的权衡。

我的2美分。

答案 1 :(得分:1)

我认为您的问题在您尝试实现的内容中有点令人困惑(获取有关SQL视图的知识或如何构建应用程序)。

我认为所有数据库逻辑都应存储在数据库层,理想情况下应存储在存储过程中,而不是存储在应用程序逻辑中。然后,应用程序逻辑应连接到数据库并从这些过程/函数中检索数据,然后在应用程序中公开此数据。

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

关于Views的直接观点,使用它们的优点包括:

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

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

    < / LI>
  • 从多个表中连接列,使它们看起来像一个表。

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

答案 2 :(得分:0)

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

答案 3 :(得分:0)

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

限制你可以用视图做什么。

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

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

答案 4 :(得分:0)

SQL视图有很多用途。首先阅读有关它们的内容,然后提出更具体的问题:

答案 5 :(得分:0)

我已经看到很多观点被用来做两件事:

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

答案 6 :(得分:0)

您所说的技术称为denormalization。来自Flickr的软件工程师Cal Henderson公开支持这项技术。

理论上JOIN操作是最昂贵的操作之一,因此非规范化是一个好习惯,因为您正在使用<转换 n 查询em> m JOIN在1个查询中, m JOIN n 查询从视图中进行选择。

那就是说,最好的方法是自己测试一下。因为对Flickr来说非常好的东西对你的应用程序来说可能不太好。

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