database - 何时存储预先计算的值与在检索它们时计算它们？

Question

我遇到了一个难题。我正在处理大量遗留代码，并且在表结构中看到大量冗余信息。它们主要以两种形式存在:

一个。用于保存“连接”的冗余信息。例如:

event_id, event_name, event_creator_id
       3       test1                43

subevent_id, event_id, event_creator_id 
         21         3               43

请注意 event_creator_id 的重复。以前的“高级”开发人员给出的基本原理是，当我们需要事件创建者 ID 时，我们只需查询一个表，而不是进行“昂贵”的连接来检索值。

B.用于节省计算的冗余信息。例如:

event_id, event_default_price
       3                  100

discount_id, discount_code, discount_percentage
          7,          ABCD,                  50

special_event_id, event_id, discount_id, discounted_price
              21         3            7,               50

请注意，代码不会为这个特殊事件计算最终的“discounted_price”(因为对 discount_id 的引用已经存在)，而是将“计算的”值保存在此处。再一次，理由是“速度”，常态化为 hell 。

我有两个问题:

1. 我可以告诉新开发人员这些结构没有规范化，但他们可以说速度更快。我该如何应对？我反对吗？其他人是否这样构建他们的数据库？!
2. 是否有经验法则或一套原则可以用来说明 - ‘哦，它会慢一些，但只会慢 1%，所以这样做没问题这个 方式等？

Answer 1

关于你的两个问题:

I can tell new developers that these structures are not normalized, but they can say its faster. How do I counter that? Do I counter that? Do others structure their databases like this?!

它可能会更快，但不一定如此:每当您决定向表中添加额外信息(在您的情况下是额外字段)时，您也会增加性能损失，因为表会变大，这可能意味着更多数据从服务器传输到客户端，或者被调入或调出内存……如果该字段用于加速查询，它可能会有一个或多个索引，这在更新和插入期间再次有性能损失.不过，要点是我在评论中暗示的一点:“缓存”和“预计算”值使系统在数据完整性方面更加脆弱。您确定“event_creator_id”始终正确指向真正的创建者，即使有人修改了原始值？如果是，这也有成本，无论是在计算方面(当创建者更改时您必须更新所有表)还是在实际开发和测试工作方面(您确定没有人忘记将更改传播到预先计算的字段？ ).

“折扣价”或运行总计等聚合值也是如此……更改原始数据可能比更改“事件创建者”信息更频繁。同样，是否有适当的“缓存失效”机制来确保每当有人完成销售时重新计算总销售额？退回的元素怎么办？有没有人考虑过确保完整性的成本？

运行总计和其他派生值应该通过使用 View 来实现，而不是，以便缓存(如果有的话)由实际的 DBMS 引擎执行，他们知道如何正确处理这个问题。

Is there a rule of thumb, or a set of principles which I can use to say that - 'oh, it will be slower, but only by 1%, so its okay to do it this way', etc?

数据库(或可以说是任何类型的计算系统)应该“首先正确”，以便您可以找到如何使其“足够快，其次”。以正确性换取速度是您在设计数据库时不应该做出的决定，除非您已经知道及时性被认为比正确性更重要。 IE。您的要求清楚地表明，拥有可能错误或过时的信息不如响应时间重要。

换句话说:设计一个带有冗余缓存信息的表是过早优化的另一个例子，应该不惜一切代价避免。

另见 this - 特别是答案