Mysql视图与PHP查询

我正在开发一个web应用程序，其中包括在各种列表中创建餐厅列表，如“Joe's必到之地”。现在，对于每个餐厅和名单，我都会在网站上显示

• 计算餐厅的知名度
• 名单的受欢迎程度
• 餐厅所在的列表数

目前我正在PHP中使用MySQL语句来实现这一点，但计划切换到MySQL视图，并在PHP中执行一个简单的select语句

我的问题是,，

---

与用PHP编写sql查询相比，使用视图的优点/缺点是什么？

如果您试图从中查看的表没有频繁更改，那么您肯定会获得性能，因为您只需从已准备好的数据中进行简单的选择。但请注意，视图并不是“一劳永逸”的——对其中一个表的内容的每一次更改都会使数据库引擎进行“视图刷新”，因此必须调用另一个查询（从中创建视图的查询），以考虑所做的更改。总而言之：

---

罕见的变化？演出频繁/持续的更改（社区添加、评论、评级您的餐厅）-最好使用SQL查询。

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

---

主要区别在于每次插入后视图都会更新，因此无论何时查询视图，数据都是“就绪”的，而使用自定义查询每次都会让MySQL计算所有内容（当然会有一些缓存）

---

底线是，如果列表的更新频率低于查看频率，您将看到使用视图时性能的一些提高。

我的完整答案取决于以下几点（从应用程序的角度）：

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

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

使用视图有两个优点：

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

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

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

---

干杯

最初的问题是关于赞成和反对的，但到目前为止，在答案中没有看到太多的缺点

视图的一个缺点不就是它们会给您运行简单查询带来虚假的舒适感吗？ 例如，从myview中选择用户名，其中id='1' 这看起来很简单，但如果“myview”是一个非常复杂的选择。。。也许甚至建立在其他观点的基础上？最终得到的是一个外观简单的查询，与从头开始编写查询相比，在后台需要做的工作要多得多

我一直在尝试使用视图，尽管有好处，但尚未完全售出。 我想听听其他人对观点的缺点的看法，而不仅仅是关于观点为何如此伟大的党的路线。可能仍会切换，但希望了解有关性能的更多信息。

缺点：

• 在我看来，数据库用于数据层，将业务代码放在数据库中是不合适的。它既降低了可维护性，又与层的干净分离相矛盾。这同样适用于在网页的java脚本中包含业务代码和计算。对于java脚本，它甚至更为严重，因为它会造成安全威胁。数据库内部代码的源代码控制也是另一个问题

• 既然代码在数据库中，安全性和访问复杂性（视图和存储过程）也被添加了

• 将应用程序从一个数据库引擎迁移到另一个数据库引擎将更加困难（因为除了简单的查询之外，存储过程/视图等也可能不同）。如果数据库只是关于数据的，那么抽象层可以允许更改数据库引擎（至少在某种程度上）

优点：

• 性能略有提高（因为数据不是从数据库中出来进行处理，而是在数据库中进行处理）

• 代码看起来更干净（因为脏东西隐藏在数据库视图、存储过程等中）

---

这个问题在我看来太宽泛了，你在考虑什么样的优势？代码可维护性？查询速度？或者什么？你为什么不发布你的ER模型或模式，然后我们可以建议优化itI的方法我想从更广阔的角度了解，需要在多个项目中使用它。使用视图。故事结束了。你的生活会轻松得多。视图使代码更清晰，您可以在其中编辑大多数数据库查询。在PHP中，确保按名称而不是数字引用列，以保持视图的可编辑性。我切换到视图，我有一些复杂的页面查询。如果我在php中有这样的功能，我会发疯的。Jason，我将我的体系结构转换为在php中使用视图而不是sql查询。我在这里说过了吗？：）我只是说频繁地更改数据库（即插入到视图包含的表中）会使视图不断更新，从而提高性能。。。跑了。好的，如果您的意思是“视图缓存”作为缓存视图查询-是的，编译后的查询被存储