php 或 mysql 数据中的计算答案

【问题标题】：Calculations in php or mysql dataphp 或 mysql 数据中的计算
【发布时间】：2012-04-08 18:26:38
【问题描述】：

我遇到了几个相同的问题，但没有一个完全相同。

哪一个更好，在从 MySql 获取结果后（通过连接几个表）在 PHP 中执行一些基本计算，或者在 MySql 中物理上拥有另一列存储总数，同时插入新行然后检索它。

例如：售出的产品：

Item         Price       Quantity      Discount
Item 1        55           100           10%

上面是一个销售表，价格列与项目表联合。基于上述问题，我们可以使用 PHP 获取结果，执行Price X Quantity X 0.10，或者我们的表格如下所示：

Item         Price       Quantity      Discount   Amount
Item 1        55           100           10%        4950

现在哪种方法更好地完成如此简单的任务？

类似的问题： Doing Calculations in MySql vs PHP

【问题讨论】：

Doing calculations in MySQL vs PHP
@DanLee，这是在 MySql 中执行计算，我的是将值存储在另一列中。
如果您添加另一列并且在更新时必须关心 2 个表，我会坚持使用加入解决方案。因为这会变得一团糟

标签： php mysql

【解决方案1】：

我会将预先计算的价格排除在表格之外。这样，如果您的折扣更改为 15%，您就不必每次都重新计算每一行的值。

【讨论】：

【解决方案2】：

我更喜欢上面的表结构，我们可以通过计算来管理所有这些事情，我们不应该将这些计算保留在 DB 中，因为我们应该遵循 RDBMS 方法

【讨论】：

【解决方案3】：

只需将计算添加到您的 SELECT 语句中。

示例：

SELECT
    ItemID,
    Price,
    Quantity,
    Discount
    Price * Quantity * Discount AS Amount
FROM myTable

或使用视图检索您想要的数据并将计算值附加为列。

这样计算的值只对请求有效，您不必向表中添加额外的列。

【讨论】：

【解决方案4】：

没有适用于所有情况的一揽子规则。许多因素会影响网站的性能和效率。所以没有单一的“最佳”。

如果您看一下 Magento 之类的东西，它会双向进行。一方面，它具有完整的 EAV 结构，每条数据都被抽象出来并标准化到第 n 级。另一方面，出于性能原因，它还会在平面表中聚合预先计算的值。这包括折扣金额、基准价格、税收数量（以基准和所选货币计）等。前一种情况在灵活性和稳健性方面最好，在性能方面平表更好。

在处理批量计算时，平面表显然可以更快，因为一切都已经解决了。但正如 kernelpanic 指出的那样，它确实意味着对设置的任何更改都可能需要对每个值进行批量重新计算。对于订单历史等历史数据，您可能不想重新计算人们最终支付的实际金额，但在确定最佳解决方案时确实需要考虑这样做的可能性。

如果性能至关重要，并且计算的运行成本很高，那么知道您可能需要不时地批量刷新值可以让您做出是否缓存它的明智决定。

但是，如果这不是性能关键方面，或者计算很昂贵但不经常运行，那么将它们排除在数据库之外会更干净，因为它们确实属于应用程序的业务逻辑处理部分，即代码。

同样，定义“最佳”的方法不止一种，因此取决于具体情况。这实际上只是平衡要求的问题——速度、清洁度、内存使用、处理器要求、磁盘空间使用、适应开发经理定义的任意数据结构的需要——你的决定需要考虑这些因素。

如果没有要解决的现实问题，猜测实际上就是所有可以给出的。如果您确实有更复杂的情况，我很乐意看看并提出我的想法。

编辑：根据我自己的观察，一个包含平面数据和超过 200k 产品的 Magento 目录页面在大约 10 到 20 秒内加载，并且没有启用页面缓存。如果禁用平面数据并使用 EAV 结构，则需要几分钟。我现在不在工作，所以我没有手边的分析数据，但这证明了在现实世界的应用程序中没有单一的最佳解决方案。

【讨论】：

【解决方案5】：

可以通过 SQL 查询在获取时或在您提取数据之后执行计算。 SQL 解决方案类似于

SELECT *, ((Price * Quantity) - ((Price * Quantity) * (Discount * .01))) AS Amount 
FROM ...

在许多方面这只是个人喜好，尽管当 SQL 开始变得非常复杂时，我发现使用起来很混乱。

您可能想要避免的是将总数保存到数据库中，除非它是一个永远不会改变的固定数量。如果您的总计已保存，并且在某个时候您更改了折扣金额或数量，则可能会忘记更新总计。如果您每次都需要从已知变量(quantity * price - discount) 计算总数，那么总数应该始终准确。

【讨论】：