存储“派生”值与在提取时计算它们

Question

当您的值仅依赖于一个或多个其他字段+/-常量(例如零售价格和折扣价格)时，在检索数据时，是也存储这些值还是“即时”计算它们更好？

Answer 1

我同意Tomislav的观点-尽量避免冗余，因为你最终可能会得到多个表上的数据彼此不一致。这使得更新更加痛苦。

不过，也有一些与数据库性能无关的例外情况值得考虑。

• 当计算值很痛苦时(例如，一些复杂的数学函数)，那么存储起来就很有意义(您可以将该列想象为“最后计算的值”)。
• 您的输入可能会随着时间的推移而发生变化，例如，费用源自费用费率，但是费率作为单个值存储在配置表中。您可能希望记录费用，因为历史费用仅从当前费用费率计算。或者，您也可以按时间存储速率，以避免此问题。
• 如果派生的值可以被用户输入或其他过程覆盖，则再次存储是有意义的。或者，您可以使用两个状态“计算”和“覆盖”对此进行建模，以便只在后一个状态中存储一个值。

Answer 2

默认情况下不存储冗余信息：third normal form通常是一个合理的初始目标。冗余是在出现“足够好”的原因时引入的，例如，当您必须计算派生值并且计算密集时，您会受到“足够大”的性能影响。

显然，“足够好”和“足够大”是限定词，它们只在给定的上下文中表示某些东西。就其价值而言，零售/折扣价格计算似乎太便宜和简单，无法保证在大多数(显然不是所有)情况下引入多余的列。