将总值存储到 SQL 数据库中是否明智？ [复制]答案

【问题标题】：Is it wise to store total values into the SQL database? [duplicate]将总值存储到 SQL 数据库中是否明智？ [复制]
【发布时间】：2018-04-17 20:03:25
【问题描述】：

我想问将总值存储到 SQL 数据库中是否是个好主意。总价值是指订单的总成本或总数量。

例如，我将有一个名为 orders 的表，其中包含创建时间、下单者等信息。Orders 将与order_items 表将保存订单中商品的 id、订单中商品的数量以及商品的销售价格（不是商品` s 原价）。

在这种情况下，我应该计算一次订单的总成本并将其存储在orders表中，还是应该每次检索带有相应商品的订单时计算？ p>

【问题讨论】：

一般来说，我会说这是不明智的。这是非规范化。它强制每个用例添加/删除或更新订单项目以更新总数，并以安全的方式执行此操作，即使两个并发请求同时添加或删除项目。但当然，总会有取舍，有时它可以让事情变得更简单或更快。特别是如果您经常只对总数感兴趣，并且每个订单有很多很多的订单商品。

【解决方案1】：

每种选择都有利有弊。如果您选择存储计算的总数，则每次更新它们所依赖的详细信息时都必须更新它们。要可靠地做到这一点，您需要在数据库附近强制执行它，例如在触发器中，而不是一直依赖业务逻辑来使其正确。

另一方面，如果您不存储计算的值，则每次您想要访问它时都必须计算它。一个视图将使这变得微不足道。

存储与重新计算的决定取决于数据更改的频率与访问频率。如果它不经常更改，那么存储该值可能没问题，但如果它经常更改，那么每次访问它时最好重新计算它。同样，如果不经常访问数据，则重新计算值是好的，而如果您经常访问它，那么预计算可能是更好的选择。

根据您使用的数据库，您可以通过创建物化视图获得两全其美的效果。

【讨论】：

【解决方案2】：

对于订单的特定情况，总金额通常与订单一起存储。然后，订单商品包含订单中每个商品的价格。

为什么？简单：某些金额仅在订单级别可用。例如：

此外，订单通常只存入数据库一次，商品没有或很少发生变化（可能要等到订单最终确定后才会进行计算）。

其他类型的实体可能有其他注意事项。这解决了是否应为订单存储总计的具体问题。

【讨论】：