これはRailsの単一テーブル継承の正当な使用ですか？

Question

私はちょうど20 Rails Development No-Nos程度チャドファウラーのブログ記事を読んでいます。単一のテーブル継承で彼はコメントします：

クラス名を保持する "タイプ"と呼ばれる列の記憶は、何か怪物が起こっていることを示す良い指標です。それは魚介類ですが、必ずしも悪くはありません。私は、あなたがそれを使うときは、それが正しい解決策であれば何度でも尋ねるべきだと思います。データベースは、STIと多相関連がたくさんあるときに、彼らが最もよくやることをしません。

私はブログアプリケーションを作成していますが、私は投稿で作成できるコメントや、訪問者が私と連絡を取りたい場合に投稿できる連絡先メッセージにSTIを使用することを検討しています。私のMessageモデルは私のCommentモデルから継承します。 Messageに余分なsubjectフィールドがあることを除いて、両方とも共通の属性を共有します。もう一つの共通点は、両方がスパムチェックのためにAkismetに提出されることです。

よりもむしろチャドが示唆するように、それは適切なソリューションだ場合だけで複数回自分自身に尋ねる、私は、同様のスタックオーバーフローの専門家からいくつかの意見を取得したいと思いました！私がSTIにうってつけのようなサウンドを提案していますか？

Answer 1

私はSTIを何度も使用してきました。彼らは、各ターンでのActiveRecordを継承する一般的なクラスから派生できBlogItemその他ページに、NewsItemの、

を持っている可能性があるCMSを考えてみましょう。それぞれの表は同じ（タイトル、本文、タグ、published_at）ですが、各モデルの関連付けやステータスが異なるか、ワークフローが異なるため、それぞれ独自のクラスにカスタムコードがあります。しかし、彼らはすべて共通のテーブルと親クラスを共有しています。また、親クラスを使用してクロスクラス検索を行い、レコードの結果の配列にキャストを自動的に入力させることもできます。

はこれを取り組むために、他の方法がありますし、そうでないかもしれない最良の例が、STIは、オブジェクトの挙動が異なる場合があります状況に便利である場合が確かにありますが、状態は同じである持続しました。もちろんこれは将来も当てはまります。あなたのケースのコメントやコンタクトメッセージで

は異なっています。それは同じテーブルにそれらを持つことによって利点がないように聞こえる。たぶん、親クラスに共有されたコードを置くか、/ libにあるモジュールに入れた方がいいでしょう。