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

我同意tomislav的观点——尽量避免冗余,因为最终会导致多个表上的数据彼此不一致。这会让更新更痛苦。

不过,也有一些与数据库性能无关的异常值得考虑。

• 当计算值(例如一些复杂的数学函数)很痛苦时,存储(可以将列想象为“最后计算的值”)是有意义的。
• 您可能有随时间变化的输入,例如,费用来自费用率,但费用率作为单个值存储在配置表中。您可能需要记录费用,因为历史费用只能根据当前费用率计算。或者,您也可以按时间存储速率以避免此问题。
• 如果派生的值可以被用户输入或其他进程重写,那么再次存储也是有意义的。或者,您可以使用“计算”和“重写”两种状态对此进行建模,以便只在后一种状态中存储值。

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

很明显,“足够好”和“足够大”是限定词,它们只在给定的上下文中有意义。就其价值而言,零售价/折扣价的计算似乎过于便宜和简单,以至于在大多数情况下(显然不是所有情况下)不需要引入多余的列。