Mysql VIEWS 与 PHP 查询答案

【问题标题】：Mysql VIEWS vs. PHP queryMysql VIEWS 与 PHP 查询
【发布时间】：2011-05-24 12:54:55
【问题描述】：

我正在开发一个网络应用程序，该应用程序涉及在各种列表中创建餐厅列表，例如“乔必须去的地方”。现在对于每个餐厅和列表，我都会在网站上显示并计算

计算餐厅的受欢迎程度
列表的流行度
餐厅所在的列表数

目前我在 PHP 中为此使用 MySQL 语句，但计划切换到 MySQL VIEWS 并在 PHP 中执行一个简单的 select 语句...

我的问题是， 使用 VIEWS 比在 PHP 中编写 sql 查询有什么优势/劣势？

【问题讨论】：

这个问题是IMO，太宽泛了，你看什么优势？代码可维护性？查询速度？还是什么？
为什么不发布您的 ER 模型或架构，然后我们可以建议优化它的方法
我想从更广泛的角度了解，需要在多个项目中使用它。
使用视图。故事结局。你的生活会轻松很多。视图使代码更清晰，您可以在其中编辑大部分数据库查询。在 PHP 中，请确保您按名称而不是按编号引用列，以保持视图可编辑。我切换到视图，我有一些针对页面运行的复杂查询。如果我在 php 中有这个，我会发疯的
感谢 Jason，我将架构切换为在 php 中使用视图而不是 sql 查询

标签： php sql mysql api architecture

【解决方案1】：

使用视图增加了一个抽象级别：您以后可以更改表的结构，并且您不必更改显示列表信息的代码，因为您仍然可以查询视图（但视图定义可能会改变）。

主要区别在于每次插入后都会更新视图，这样每当您查询视图时数据就“准备就绪”，而使用自定义查询将使 MySQL 每次都计算所有内容（当然有一些缓存） .

底线是，如果您的列表更新频率低于查看频率，您会看到使用视图的性能有所提升。

【讨论】：

“每次插入后都会更新视图”——你是什么意思？您是否暗示视图是事先计算和缓存的？
如果你使用 MySQL，也许你可以看看dev.mysql.com/doc/refman/5.7/en/view-algorithms.html。你有两种方法，一个临时表和一个内联模式。在这两个视图中，SQL 都被执行，在MERGE 中，它被“粘贴”在调用 SQL 中，但在 TEMPTABLE 中创建了一个临时表并填充了查询数据（因此可以释放锁）。

【解决方案2】：

我的完整答案取决于几件事（从您的应用程序的角度来看）：

您是否计划允许用户创建和共享此类列表？
用户可以创建任何类型的列表，还是仅通过将值插入现有查询模板来创建？

假设您有几个预定义的列表要显示：

使用视图有几个优点：

你的代码会更干净
生成视图的查询不必每次都由 mysql 解析。

对此我不确定：我不认为 mysql 会像 Tomasz 建议的那样缓存视图 - 我不认为视图包含“已经准备好的数据”。

一个缺点是创建列表所涉及的逻辑进入数据库而不是存在于您的 PHP 代码中——我非常反对这种做法。在我的世界中，数据库用于数据，代码用于逻辑。

干杯

【讨论】：

我在哪里说过这个？ :) 我只说频繁更改数据库（即插入视图组成的表）会使视图不断更新，因此性能......消失了。好吧，如果您的意思是“视图缓存”作为缓存视图查询 - 是的，当用户尝试从视图中获取数据时，已编译的查询将被存储和使用。视图不“包含”数据，我的意思只是一个事实，即数据库引擎保存准备好的数据以用于视图，它不是“动态”计算的，每个请求。
嗯。我肯定是误会了。
@TomaszKowalczyk 你能把我链接到你看到数据准备在视图中使用的地方吗？从阅读中可以看出，查询在后台像往常一样运行（使用连接、联合等），因此实际上并没有任何性能优势。编辑：我认为你在谈论 Temptable Views。它们没有索引，因此查询大表会很慢。我不确定这是否值得，除非您只有少量行。
如果你使用 MySQL，也许你可以看看dev.mysql.com/doc/refman/5.7/en/view-algorithms.html。你有两种方法，一个临时表和一个内联模式。在这两个视图中，SQL 都被执行，在MERGE 中，它被“粘贴”在调用 SQL 中，但在 TEMPTABLE 中创建了一个临时表并填充了查询数据（因此可以释放锁）。

【解决方案3】：

最初的问题是关于利弊的，但到目前为止，在答案中没有看到太多关于缺点的问题。

视图的一个缺点难道不是它们会给您运行简单查询的虚假舒适感吗？例如， SELECT username FROM myview WHERE id='1' 这看起来很简单，但如果“myview”是一个非常复杂的 SELECT 怎么办……甚至可能建立在其他视图之上？您最终会得到一个看起来很简单的查询，与从头开始编写查询相比，它在后台需要更多的工作。

我一直在试验视图，尽管有好处，但尚未完全售出。我很想听听其他人对观点的缺点的看法，而不仅仅是关于观点为何如此出色的党派路线。可能仍会进行转换，但想了解更多有关性能的信息。

【讨论】：

【解决方案4】：

如果您尝试从中创建视图的表不会经常更改，那么您肯定会获得性能，因为您只是从已经准备好的数据中进行简单的选择。但请注意，该视图不是“一劳永逸”的东西 - 其中一个表的内容的每次更改都会使数据库引擎执行“视图刷新”，因此另一个查询（查询您正在制作视图from) 必须调用 taki 以考虑所做的更改。总结一下：

不经常更改？表现。频繁/持续的变化（社区添加、评论、评价您的餐厅）- 最好使用 SQL 查询。

【讨论】：

【解决方案5】：

缺点：

在我看来，数据库用于数据层，将业务代码放入其中并不合适。它既降低了可维护性，又与层的干净分离相矛盾。这同样适用于在网页的 java 脚本中包含业务代码和计算。对于 java 脚本，它甚至更严重，因为它会产生安全威胁。数据库内部代码的源代码控制也是另一个问题。
现在代码在数据库中，安全性和访问复杂性（视图和存储过程）也增加了。
将应用程序从一个数据库引擎迁移到另一个会更加困难（因为除了简单的查询之外，存储过程/视图等也可能不同）。如果数据库只是关于数据，那么抽象层可以允许更改数据库引擎（至少在某种程度上）。

优点：

性能略有提升（因为数据不是从数据库中出来进行处理，而是直接在数据库内部进行处理）。
代码看起来更干净（因为脏东西隐藏在数据库视图、存储过程等中）。

【讨论】：