规范化或不规范化 user_ids

Question

在我的 Rails 应用程序中，我有各种包含用户数据的数据库表。其中一些表有很多行（在某些情况下，每个用户多达 500,000 行）并且经常被查询。每当我查询任何表的任何内容时，当前用户的 user_id 都在查询中的某个位置 - 如果表与用户有直接关系，则直接，如果它们通过其他表相关，则通过连接。

我是否应该对 user_id 进行非规范化并将其包含在每个表中，以获得更快的性能？

---

这是一个例子：

• 地址属于用户，并且有一个user_id
• 信封属于用户，并且有一个user_id
• AddressesEnvelopes 连接了地址和信封，因此它具有信封_id 和地址_id - 它没有用户id，但可以通过信封或地址（必须属于同一用户）来获取它。李>

一个常见的昂贵查询是为特定用户选择所有 AddressesEnvelopes，我可以通过加入 Address 或 Envelope 来完成，即使我不需要这些表中的任何内容。或者我可以在此表中复制用户 ID。

---

这是一个不同的场景：

• 字母属于用户，并且有一个 user_id
• 收件人属于 Letter，并且有一个 letter_id
• RecepientOption 属于 Recepient，并且有一个 recepient_id

在 Recepient 和 RecepientOption 中复制 user_id 是否有意义，即使我总是可以通过关联、通过 Letter 来获得它？

---

一些注意事项：

• 从来没有任何对象是 用户之间共享。一个完整的 相关对象的层次结构总是 属于同一用户。
• 对象的用户所有者永远不会改变。
• 数据库性能很重要，因为它是一个数据密集型应用程序。有很多查询和很多表。

---

那么我应该在每个表中包含 user_id 以便在创建索引时使用它吗？或者那会是糟糕的设计？

Answer 1

我想指出，如果您愿意使用复合主键，则没有必要进行非规范化。 AddressEnvelop 案例示例：

user(
    #user_id
)
address(
    #user_id
,   #addres_num
)
envelope(
    #user_id
,   #envelope_num
)
address_envelope(
    #user_id
,   #addres_num
,   #envelope_num
)

（#表示主键列）

如果可以避免的话，我不是这种设计的粉丝，但考虑到您说所有这些对象都与用户相关联这一事实，这种类型的设计将使您的数据分区相对简单（无论是逻辑上的，将用户范围放在单独的表中或物理上，使用多个数据库甚至机器）

对这种设计有意义的另一件事是使用聚集索引（在 MySQL 中，InnoDB 表的主键是从聚集索引构建的）。如果您确保 user_id 始终是索引中的第一列，它将确保对于每个表，一个用户的所有数据都紧密地存储在磁盘上。当您总是按 user_id 查询时，这很好，但如果您按另一个对象查询，它可能会损害性能（在这种情况下，像您建议的那样重复可能是更好的解决方案）

无论如何，在您更改设计之前，首先要确保您的架构已经优化，并且您的外键列上有正确的索引。如果性能真的很重要，您应该尝试几种解决方案并进行基准测试。

Answer 2

只要你

a) 获得可衡量的性能提升

和

b) 知道数据库的哪些部分是真正的规范化数据，哪些是冗余改进

没有理由不这样做！

Answer 3

你真的有测量性能问题吗？ 500 000 行不是很大的表。如果它们不是很复杂并且您的列上有适当的索引，那么您的选择应该是合理的快速。

我会先看看是否有慢查询，然后尝试使用索引来优化它们。如果这还不够，那么我会研究非规范化。

如果您无法通过其他方式获得所需的性能，您建议的非规范化似乎是合理的。只需确保使非规范化字段保持最新即可。