Rails 多態索引

Question

我正在研究 Rails 多態列，例如可以“喜歡”的多個模型的“可愛”。 IE。 一個帖子模型有has_many :likes, as: :likable

表likes需要一個likable_id （一個整數）和一個likable_type （一個字符串）

與根本不使用這種多態設計相反。 那豈不是對速度和內存更優化的，而不是用在非多態場like

IE。 like的模式是

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

在這種情況下，您還可以獲得每列被索引到適當的數據庫表中的額外好處

IE。

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

據我所知，多態設計僅提供“更干凈”和更多面向對象的好處，但不利的一面確實減少了優化。

一個字符串會占用更多空間，特別是如果像likes這樣的表呈指數增長。

並且比較整數與字符串以及相關表上沒有索引會更慢。

所以我的問題是為什么有人應該使用這個功能？

Answer 1

如果你想避免多態索引，你要么需要將你的“喜歡”分解成單獨的關聯表，例如post_likes和comment_likes ，或者嘗試使用單表繼承（STI）以某種方式將這些表組合在一起，其中關系總是在一張桌子和另一張桌子。

添加一整堆列會使您的“喜歡”表變得混亂並混淆其目的。 您不想要這樣的扇出關聯，它只會把事情弄得一團糟，特別是因為您希望連接表在兩個鍵列上具有NOT NULL屬性和UNIQUE約束。

始終努力做最簡單的事情，尤其是在小規模的情況下。 如果您需要將其提升到處理數十億個贊，您將對使用模式、讀/寫活動方面的痛點有更好的了解，並且已經對如何處理更多記錄有了想法。 您可能會發現需要對其進行分片、水平分布，或者可能使用表分區。 您可能還會發現可以使用 NoSQL 數據庫更好地處理數據，但您不知道，因為您無法預測未來。

我強烈建議現在使用帶有簡單索引的多態關聯，看看效果如何。 如果您擔心，請加載數百萬行數據以查看其性能。 我想你會感到驚訝。 我見過像這樣的系統處理數億條記錄而不會跳過一個節拍，即使在非常普通的硬件上運行也是如此。