哪种方式最好将销售信息存储在数据库中：
答案 0 :(得分：7)
存储每个项目的所有单个详细信息，因为您以后通常需要它们（出于统计/信息目的或任何其他原因）。您必须确保始终遵循相同的计算逻辑来获得总销售价格。所以你可能需要存储货币，折扣，价格单位等等。这里还有一些要考虑的要点：
如果您想稍后输出单项价格，则需要单项数据。
不要将总价格与单项数据一起保存，因为您必须始终保持同步。一个月/几年后你会感到困惑，关于用于计算的两种情况。
如果您在数据仓库中使用数据并且不需要详细信息，请汇总数据。
答案 1 :(得分：6)
这是3rd Normal Form问题。
选项1是第3范式。没有派生数据。必须为每个查询进行计算。因此，可以在任何字段上进行更新而不会破坏任何内容。
选项2打破第3范式。它保存派生数据。计算不是在查询时完成的，因此更快。但是，不会重做计算的更新将导致数据不一致。这被称为“更新异常”。更新导致派生数据字段不一致。
此外 - 根据计算结果 - 当需要更改派生数据时，可能无法推断应哪些字段会发生变化。
答案 2 :(得分：1)
这取决于您将如何处理数据。
出于很多目的，在每个项目下存储该项目的单价，购买数量和延长价格是值得的。延长价格是数量乘以单价。这是多余的吗？嗯，是。它是否违反了某种正常形式？嗯，是。但它运作得很好。
为什么要将价格存储在商品行（记录）中，而不仅仅依赖于主产品表中存储的相同价格数据？因为如果您在此次促销后更改价格，则不希望更改此客户在此次购买时产生的价格。为什么存储延长价格，因为这可以在运行中重新计算？因为它使得稍后对某些项集合（总和或平均）更简单一步。
如果存储扩展价格，您可以使用这些点和点击，向下钻取分析工具（请参阅OLAP）以供以后分析，无需进一步编程。如果您指望在需要时重新计算延长价格，您可能会发现向下钻取工具不够智能，无法为您进行乘法运算。
“项目”通常是某些较大工作单元的子项。在开票系统中，项目是发票的一部分。在总帐系统中，项目是交易的一部分。这些项目不平衡，但交易是。在如今的许多商业系统中，发票功能和会计功能都是从同一个数据库驱动的，但这超出了你的问题。
通常情况下，我会尝试将数据标准化。这是许多专家故意偏离纯正规化要求的地方。
答案 3 :(得分：0)
我会说你总是将成本和价格存储为单独的列并存储总数。有一段时间你需要那些你会后悔的（报告，发票）。
如果您存储计算值，问题将会真正成为问题。这将真正取决于应用程序的情况（多少行，多少交易等）。如果它是一个中小型应用程序，它可能对性能无关紧要，所以这只是其他因素的问题。
如果总计的公式可能变得更复杂（例如税，折扣等），您可能想要存储总数。否则，不得不在其他领域复制这种逻辑可能会非常困难。
我个人总是存储总金额。我只是发现额外数据库列的成本总是超过其他地方的总和。
答案 4 :(得分：0)
我会存储物品的成本和每件物品的销售价格。如果您只存储总计，那么如果价格发生变化，您将很难重新计算价值。想象一下，对某些商品给予季节性折扣，对某些商品应用不同的税（甚至可能根据客户的原产国不同，或者为注册客户降低价格） - 您必须根据销售额计算这些价格物品的价格，在这种情况下总数是没用的。
如果你真的需要总数，你可以随时使用简单的数据库查询轻松计算它们，同时考虑所有折扣等等。
答案 5 :(得分：0)
恕我直言，每件商品的成本和销售额。如果希望结果像总计一样，则可以在Query中执行它们，也可以使用计算创建临时表或存储过程。但是，我通常在代码中执行这些计算（在我的情况下是PHP或JAVA）。 如果它仅用于报告目的，有时可以将总计存储为加速计算（并防止在代码中进行一些错误计算）。
答案 6 :(得分：0)
如果我有一个严重的报告问题，我只会存储总数，其中许多查询需要大量记录的总值（如果您只获得一小组的总数，请在需要时即时计算它） ）。
如果存储总计，则需要触发器以确保更新，删除和插入所有内容都能正确更新总计。否则，数据将不同步且无用。