在MySQL和PHP中进行计算

Question

内容：

• 我们有一个PHP / MySQL应用程序。
• 计算的某些部分直接在SQL中完成。例如：最近24小时内创建的所有用户都将通过SQL查询返回（NOW（）– 1天）

我和其他开发人员之间正在进行辩论，我认为我们应该这样做：

A.将所有计算/代码/逻辑保存在PHP中，并将MySQL视为“愚蠢的”信息存储库

他的意见：

B.根据更简单/更快的方式进行混合搭配。http://www.onextrapixel.com/2010/06/23/mysql-has-
functions-part-5-php-vs-mysql-
performance/

我正在研究可维护性的观点。他正在研究速度（如本文所指出，MySQL中的某些操作更快）。

@ bob-the-destroyer @tekretic @OMG小马@mu太短@Tudor Constantin @tandu @Harley

我同意（并且很显然）高效的WHERE子句属于SQL级别。但是，类似这样的示例呢？

1. 使用NOW（）-SQL中的1天来选择过去24小时内创建的所有用户来计算24个期间？
2. 返回所有用户的大写名字和姓氏？
3. 连接字符串？
4. （想法，伙计？）

清除属于SQL域的示例：

1. 具体的WHERE选择
2. 嵌套SQL语句
3. 订购/排序
4. 选择DISTINCT项目
5. 计算行/项目

Answer 1

我会发挥每个系统的优势。

聚合，联接和过滤逻辑显然属于数据层。它的速度更快，这不仅是因为大多数数据库引擎为此进行了10多年的优化，而且还可以最大程度地减少数据库和Web服务器之间转移的数据。

另一方面，我使用的大多数数据库平台在处理单个值时的功能都很差。日期格式和字符串操作之类的东西在SQL中很烂，最好在PHP中完成。

基本上，使用每个系统来完成其工作。

在可维护性方面，只要清楚区分发生在何处，将它们与逻辑类型分开就不会造成太大问题，当然也不足以抵消收益。在我看来，代码的清晰度和可维护性更多的是一致性，而不是将所有逻辑放在一个地方。

回复：具体例子…

1. 我知道这也不是您所指的，但日期几乎是一种特殊情况。您要确保系统生成的所有日期都在Web服务器或数据库上创建。如果将db服务器和web服务器配置为不同的时区，则否则会导致一些隐患（我见过这种情况）。想象一下，例如，您createdDate有一个默认值为 DB 的列getDate()应用于 DB 。如果您要插入一条记录，那么使用 PHP中 生成的日期（例如date("Y-m-d", time() - 3600)，选择在过去一小时内创建的记录，您可能无法获得期望的结果。对于您应该在哪一层上执行此操作，我希望使用DB例如，它使您可以使用列默认值。

2. 对于大多数应用程序，我会在PHP中执行此操作。混合姓氏和名字听起来很简单，直到您意识到有时也需要在其中使用称呼，标题和中间缩写。另外，您几乎肯定会以想要用户的名字，姓氏和组合称呼+姓氏+姓氏为最终结果。将它们串联在DB端意味着您最终将移动更多的数据，尽管实际上，它很小。

3. 依靠。如上所述，如果您想单独使用它们，则最好从性能角度考虑，将它们分别拉出并在需要时进行连接。也就是说，除非您要处理的数据集庞大，否则可能还有其他因素（如您提到的可维护性）具有更大的影响力。

一些经验法则：

• 生成增量ID应该在数据库中进行。
• 就个人而言，我喜欢数据库所应用的默认设置。
• 选择时，任何减少记录数量的操作都应由数据库来完成。
• 这样做通常可以减少数据集DB端的大小（例如上面的字符串示例）。
• 正如你所说；排序，聚合，子查询，联接等应始终在DB端。
• 另外，我们还没有讨论它们，但是触发器通常是坏的/必要的。

在这里您需要面对一些核心的权衡，而平衡实际上取决于您的应用程序。

有些事情绝对应该总是在SQL中完成。排除许多任务的某些异常（如日期事件），SQL可能很笨拙，并且可能使您陷入逻辑混乱的境地。例如，在代码库中搜索对特定列的引用时，
很 容易错过视图或存储过程中包含的内容。

性能始终是一个考虑因素，但取决于您的应用程序和特定示例，可能并不是一个大问题。您对可维护性的担忧可能非常有效，而我提到的一些性能优势却很少，因此请提防过早优化。

另外，如果其他系统正在直接访问数据库（例如，用于报告或导入/导出），您将受益于数据库中更多的逻辑。例如，如果要直接从另一个数据源导入用户，则可以在SQL中实现类似电子邮件验证功能的重用。

简短的答案：这取决于。:)