mysql - Rails 多态性索引

Question

我正在研究 Rails 多态列，例如“喜欢”的多个模型可以“喜欢”。IE。邮政模型有has_many :likes, as: :likable

表likes需要一个likable_id(整数)和likable_type(字符串)

完全反对使用这种多态设计。在 like

中使用非多态字段对于速度和内存来说不是更优化吗？

即。 like 的架构是

t.integer  "post_id"
t.integer  "comment_id"
t.integer  "etc_id"

在这种情况下，您还可以获得将每列索引到适当的数据库表中的额外好处

即。

t.index ["post_id"], name: "index_likes_on_post_id", using: :btree

据我所知，多态设计仅提供“更干净”和更多面向对象的好处，但缺点是会降低优化。

字符串会占用更多空间，尤其是当像 likes 这样的表呈指数增长时。

比较整数和字符串会更慢，而且相关表上没有索引。

所以我的问题是为什么有人应该使用这个功能？

Answer 1

如果您想避免多态索引，您需要将您的“喜欢”分解为单独的关联表，例如 post_likes 和 comment_likes，或者尝试组合这些表以某种方式使用单表继承 (STI) 组合在一起，其中关系始终位于一个表与另一个表之间。

添加一大堆列会使您的“喜欢”表变得困惑并混淆其用途。您不想要这样的扇出关联，它只会让事情变得一团糟，特别是因为您希望连接表具有 NOT NULL 属性和 UNIQUE 约束在两个关键列上。

始终努力做最简单、有效的事情，尤其是在小规模的情况下。如果您需要提升此功能以处理数十亿个点赞，您将更好地了解使用模式、读/写事件方面的痛点，并且已经了解如何处理更多记录。您可能会发现需要对其进行分片，水平分散，或者可能使用表分区。您可能还发现可以使用 NoSQL 数据库更好地处理数据，但您不知道，因为您无法预测 future 。

我强烈建议现在使用多态关联和一个简单的索引，看看效果如何。如果您担心，请加载数百万行数据以查看其性能。我想你会感到惊讶。我见过这样的系统可以毫不犹豫地处理数亿条记录，即使在非常普通的硬件上运行也是如此。