ruby-on-rails - これは Rails の単一テーブル継承の正当な使用法ですか?

Question

20 Rails Development No-Nosに関する Chad Fowler のブログ投稿を読んだところです。単一テーブルの継承について、彼は次のようにコメントしています。

クラス名を保持する「タイプ」と呼ばれる列のストレージは、何か怪しいことが起こっていることを示すかなり良い指標です。怪しいですが、必ずしも悪いわけではありません。ただし、それを使用するときはいつでも、それが正しい解決策であるかどうかを何度も自問する必要があると思います. STI やポリモーフィックな関連付けが多い場合、データベースは本来の性能を発揮できません。

私はブログアプリケーションを書いていますが、投稿に付けられるコメントと、訪問者が私に連絡したい場合に投稿できる連絡先メッセージに STI を使用することを検討しています。私のモデルは私のMessageモデルを継承しCommentます。どちらも共通の属性を共有しますMessageが、追加のsubjectフィールドがあります。もう 1 つの共通点は、両方がスパム チェックのために Akismet に送信されることです。

チャドが提案するように、それが正しい解決策であるかどうかを何度も自問するのではなく、スタックオーバーフローの専門家からも意見を得ると思いました! 私が提案していることは、STI に適しているように聞こえますか?

Answer 1

STIを数回使用しました。Page、NewsItem、BlogItem などを持つ CMS を考えてみましょう。

それらはそれぞれ、ActiveRecord を継承する共通のクラスから派生する可能性があります。それぞれのテーブル (タイトル、本文、タグ、published_at) は同じですが、各モデルには異なる関連付け、異なるステータス、または異なるワークフローがあるため、それぞれ独自のクラスにカスタム コードがあります。それでも、それらはすべて共通のテーブルと親クラスを共有しています。また、親クラスを使用してクロスクラス検索を行い、結果のレコードの配列を自動的に型キャストすることもできます。

これに対処する方法は他にもあり、最良の例ではないかもしれませんが、オブジェクトの動作が異なる可能性があるが永続化された状態が同じ場合に STI が便利な場合があります。もちろん、これが将来も当てはまることを確認する必要があります。

あなたの場合、コメントと連絡先メッセージは異なります。それらを同じテーブルに置くことには利点がないように思えます。共有コードを親クラスに配置するか、/lib のモジュールに配置することをお勧めします。