Question

我正在设计一个跟踪订单的应用。每个订单都可以具有＆gt; 1个workItem，每个workItem可以有单独的价格。

我正在将workItem的价格存储在workItem表中，认为在UI或报表中，收集工作成本（向客户收取费用并支付给承包商）将通过查询现有成本来计算workItems表中的数据。

以这种方式保留或将总金额存储在Order表中是否有意义？如果我选择后者，数据是不是多余的？也许有这种举动的性能考虑因素。你觉得怎么样？

Answer 1

这取决于您的数据库的使用方式。

理想的解决方案是将单独的项目保留在工作项目行中。这样可以避免重复数据。例如，当您添加或更新工作项时，否则您必须同时更新工作项和总计。

使用适当的索引，这样的查询通常具有高性能：

SELECT i.*, SUM(wi.amount) total
FROM invoice i
JOIN workitem wi ON i.invoice_id = wi.invoice_id
GROUP BY i.invoice_id

话虽如此，如果您发现性能问题，您可能会对数据模型进行非规范化并存储总数。但是如果你需要的话，只能走那条路。在我看来，不应该先发制人。

Answer 2

如果您遵循规范化规则，您将省略计算值，例如总计并立即生成它们。

但是，有时你可能会选择对一点进行去标准化并明确存储这些值。

就存储空间而言，目前在大多数平台上通常不会出现问题，因此存储额外数据不是问题。有时，当以这种方式去标准化时，您可以提高性能或简化代码。同样，您的决定也会影响可维护性，或者可能会增加复杂性。

在您的示例中，如果您根据订单存储总计，则每次修改项目时，您都会访问工作项目表，然后您还必须更新订单表。这似乎没有什么好处，所以我不会走这条路......但正如我所说，有时候你可能明智地选择存储数据，而不是在运行中得到它。

Answer 3

正如您所说，性能和使用是这里正确决策的关键。什么是正确的决定现在可能不会在未来。

要求可能是列出仅显示总价值的所有订单。如果您不存储该值，则必须汇总每个订单的订单项才能获得总计。如果您将此值与订单表一起存储，则您不需要在表格中包含订单商品。

您可以将这种想法扩展到订单商品的数量。可以计算该值，但如果在概述中需要，可以获得大的性能增益，只需将其与订单表一起存储即可。

Answer 4

除非性能成为问题，否则我不会将总数存储在您的数据库中。

而是根据报告或显示的需要动态计算。