我正在使用存储在数据库中的数据构建一个新的 Web 应用程序。与许多 Web 应用程序一样，我需要从复杂的 sql 查询中公开数据（使用多个表中的条件进行查询）。我想知道在数据库中将我的查询构建为 sql 视图而不是在应用程序中构建它是否是一个好主意？我的意思是这样做有什么好处？数据库性能？我会写更长的代码吗？调试时间更长？
谢谢
【问题讨论】：
标签： mysql sql sql-server
这个问题无法真正客观地回答，因为这取决于具体情况。
通过视图、函数、触发器和存储过程，您可以将应用程序的部分逻辑移动到数据库层。
这有几个好处：
但也有一定的缺点：
如果您坚持使用SQL92 standard，这是一个很好的权衡。
我的 2 美分。
【讨论】：
我认为您的问题在您想要实现的目标方面有点令人困惑（获得有关 SQL 视图或如何构建应用程序的知识）。
我相信所有数据库逻辑都应该存储在数据库层，最好是存储在存储过程中，而不是存储在应用程序逻辑中。然后应用程序逻辑应该连接到数据库并从这些过程/函数中检索数据，然后在您的应用程序中公开这些数据。
将其存储在数据库层的好处之一是通过 SQL Server 来利用执行计划（您可能无法通过应用程序逻辑直接访问它）。另一个优点是您可以分离应用程序，即如果需要更改数据库，您不必直接修改应用程序。
对于视图的直接点，使用它们的优点包括：
将用户限制为表中的特定行。 例如，允许员工在劳动力跟踪表中仅查看记录其工作的行。
将用户限制为特定列。 例如，允许不在工资单中工作的员工查看员工表中的姓名、办公室、工作电话和部门列，但不允许他们查看任何包含工资信息或个人信息的列。
连接多个表中的列，使它们看起来像一个表。
http://msdn.microsoft.com/en-us/library/aa214068(v=sql.80).aspx
【讨论】：
我个人更喜欢视图，尤其是对于报告/应用程序，因为如果数据中存在任何问题，您只需更新单个视图，而不是重新构建应用程序或手动编辑查询。
【讨论】：
SQL 视图有很多用途。尝试先阅读它们，然后问一个更具体的问题：
【讨论】：
我看到视图被大量用于做两件事：
table 1: Name, Last_name, User_ID, credit_card, social_security。你创建一个视图表。table view: name, last_name, user_id。【讨论】：
您可能会遇到性能问题和可以针对视图运行的类型查询的限制。
限制您可以对视图执行的操作。
根据我的经验，一个索引良好的表、使用正确的引擎并经过适当调整（例如设置适当的 key_buffer 值）可以比视图执行得更好。
或者，您可以创建一个触发器，根据其他表的结果更新一个表。 http://dev.mysql.com/doc/refman/5.6/en/triggers.html
【讨论】：
你说的技术叫denormalization。 Flickr 的软件工程师 Cal Henderson 公开支持这项技术。
理论上JOIN 操作是最昂贵的操作之一，因此非规范化 是一个很好的做法，因为您正在使用 转换n 个查询m JOIN 在 1 个查询中，m JOIN 和 n 从视图中选择的查询。
也就是说，最好的方法是自己测试它。因为对 Flickr 可能非常好的东西可能对您的应用程序没有那么好。
此外，从一个 RBDMS 到另一个，视图的性能可能会有很大差异。例如，根据 RBDMS 视图可以在原始表更改时更新，可以有索引等。
【讨论】：