Rails多態性指數

我正在尋找Rails多態列，比如'喜歡'多個可以「喜歡」的模型。即。一個Post模型具有 has_many :likes, as: :likableRails多態性指數

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

至於我可以告訴多態性設計只提供作爲「乾淨」，更OO的好處，但是，缺點的確降低優化。

一個字符串將佔用更多的空間，特別是如果像likes這樣的表類似指數增長。

而且它將比較ints與字符串以及相關表格上的索引來比較慢。

所以我的問題是爲什麼任何人都應該使用這個功能？

來源

2017-09-26 pottedmeat7

我不確定，但如果存在，它可能已經在性能方面進行了測試驗證。我使用適用於不同模型的聊天室的多態關聯。可消息模型確實包含一些數據。在你的情況下，喜歡沒有數據，它只是一個增量。有可能比你提到的更好的解決方案。你也必須記錄喜歡的用戶。所以他可以不像他想要的。喜歡的特徵比我們想象的更復雜，可能有線程解釋不同的技術。 – Maxence

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

添加一大堆列會混淆「喜歡」表並混淆其目的。你不需要這樣的扇出關聯，它只會讓事情變得混亂，尤其是因爲你想讓你的連接表在兩個關鍵列上有NOT NULL屬性和UNIQUE約束。

總是努力做最簡單的工作，特別是小尺度。如果您需要加強處理數十億的喜好，您將會對使用模式有更好的理解，並且在讀/寫活動方面會有痛點，並且已經對如何處理更多記錄有了一些想法。你可能會發現你需要將它分片，水平分散或者使用表分區。你也可能發現你可以使用NoSQL數據庫來更好地處理數據，但是你不知道，因爲你無法預測未來。

我強烈建議現在使用一個多態關聯與一個簡單的索引，看看如何。如果您擔心，請將其加載數百萬行數據以查看其效果。我想你會感到驚訝。我看到這樣的系統可以處理數億條記錄，即使在非常適中的硬件上運行時也不會跳動。

來源

2017-09-27 01:31:40 tadman

Rails多態性指數

回答

相關問題