Mysql VIEWS与PHP查询

时间:2010-12-13 08:18:06

标签: php sql mysql api architecture

我正在开发一个网络应用程序,其中包括创建各种列表中的餐馆列表,例如“Joe必须访问的地方”。现在每个餐厅和列表,我都在网站上显示计算

  • 计算餐厅的受欢迎程度
  • 列表的受欢迎程度
  • 中餐厅的列表数量

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

我的问题是, 使用VIEWS而不是在PHP中编写SQL查询有什么优点/缺点?

5 个答案:

答案 0 :(得分:15)

使用视图添加抽象级别:您可能稍后更改表的结构,而不必更改显示列表信息的代码,因为您仍然会查询视图(视图定义可能会改变)。

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

最重要的是,如果您的列表的更新频率低于查看频率,那么您在使用视图时会看到一些性能提升。

答案 1 :(得分:4)

我的完整答案将取决于几个方面(从您的应用程序的角度来看):

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

假设您要显示几个预定义列表:

使用视图有以下几个优点:

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

我不确定这一点:我不认为mysql会像Tomasz所暗示的那样缓存视图 - 我不认为视图包含“已预先分配的数据”。

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

干杯

答案 2 :(得分:4)

最初的问题是关于利弊,但到目前为止答案中没有看到很多不利因素。

视图的一个缺点是,它们可以为您提供运行简单查询的错误安慰吗? 例如,SELECT username FROM myview WHERE id ='1' 这看起来很简单,但是如果“myview”是一个非常复杂的SELECT ...或者甚至建立在其他视图上呢?你最终会得到一个简单的查询,在后台,你需要做的工作比你从头开始编写查询要多得多。

我一直在试验观点,尽管有好处,但尚未完全销售。 我有兴趣听听其他人对于观点的缺点的看法,而不仅仅是关于为什么观点如此之大的派对。可能仍会进行切换,但想了解更多有关性能的信息。

答案 3 :(得分:3)

如果您尝试进行查看的表不会经常更改,那么您肯定会获得性能,因为您只是从已准备好的数据中进行简单的选择。但请注意这样一个事实,即该视图不是“一次又一次”制作的 - 其中一个表的内容的每次更改都会使数据库引擎“查看刷新”,因此另一个查询(查询您正在查看) from)必须要考虑到taki的变化。总结一下:

不经常的变化?性能。频繁/不断变化(社区添加,评论,评价您的餐馆) - 最好使用SQL查询。

答案 4 :(得分:-1)

缺点:

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

  • 现在代码在数据库内部,还增加了安全性和访问复杂性(对于视图和存储过程)。

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

优点:

  • 轻微的性能提升(因为数据不是来自数据库进行处理,而是直接在数据库内处理)。

  • 代码看起来更干净(因为数据库视图,存储过程等中隐藏了肮脏。)