我正在使用存储在数据库中的数据构建新的Web应用程序。尽可能多的Web应用程序,我需要从复杂的SQL查询中公开数据(从多个表中查询条件)。我想知道在数据库中构建我的查询作为sql视图而不是在应用程序中构建它是否是一个好主意?我的意思是什么会有什么好处?数据库性能?我会更长时间编码吗?调试时间更长?
谢谢
答案 0 :(得分:5)
这不能客观地回答,因为它取决于具体情况。
使用视图,函数,触发器和存储过程,您可以将应用程序的部分逻辑移动到数据库层中。
这可以有几个好处:
但也有某些缺点:
如果坚持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)
我已经看到很多观点被用来做两件事:
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视图可以在原始表更改时更新,可以有索引等。