Rails-STIを使用するかどうか…それが問題です
6か月前に、アプリのデータのモデル化について質問し、STIに向けてアドバイスを求めました(詳細については、Railsデータモデル-ベストプラクティスの質問を参照してください)。 私はそれをいじって、それをいくらか動かして、それから気を散らして、プロジェクトを休止状態にしました。 プログラミング/ RORの6か月の経験を活かして、ゼロから再び開発を始めたところ、ビールレシピの材料をモデリングする際に、再びこの壁にぶつかりました。 簡単に要約すると、3つの成分タイプ(麦芽、ホップ、および酵母)があるとします。それぞれがいくつかの属性(名前、価格、ベンダー)を共有しますが、それぞれにその成分タイプに固有の属性もあります。それらはすべて関連しています(それらはすべて成分です)が、「動作」は異なります(たとえば、穀物がすりつぶされ、ホップ/酵母などに適用されないものに対処するロジックが存在するなど)。 成分が十分に異なるので、dbに3つの別個のテーブルを置くことだけを考えています...しかし、コントローラーについてはどうですか?単一の成分コントローラーを使用して個別のモデルを管理できますか? 私はSTIの代替(クラステーブルの継承、およびマルチテーブルの継承)について読みましたが、すべてのソリューションは扱いにくいようです。STIの便利さ(タイプに関係なく、単一のテーブルクエリですべての成分を取得するなど)の欠点がない(nullフィールド、サブクラスやフィールドを追加し続けると扱いにくいテーブルなど)代替手段はありますか? 申し訳ありませんが、この質問は少しあいまいですが、明確な解決策を見つけることができないように感じ、現在、どちらの方法がより悪が少ないかを理解しようとしています。他の人もこれに対処していると思います。さまざまなソリューションの長所と短所を聞きたいです。ありがとう!