我正在使用存储在数据库中的数据构建新的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视图可以在原始表更改时更新，可以有索引等。