Rails-STIを使用するかどうか…それが問題です

6か月前に、アプリのデータのモデル化について質問し、STIに向けてアドバイスを求めました（詳細については、Railsデータモデル-ベストプラクティスの質問を参照してください）。

私はそれをいじって、それをいくらか動かして、それから気を散らして、プロジェクトを休止状態にしました。

プログラミング/ RORの6か月の経験を活かして、ゼロから再び開発を始めたところ、ビールレシピの材料をモデリングする際に、再びこの壁にぶつかりました。

簡単に要約すると、3つの成分タイプ（麦芽、ホップ、および酵母）があるとします。それぞれがいくつかの属性（名前、価格、ベンダー）を共有しますが、それぞれにその成分タイプに固有の属性もあります。それらはすべて関連しています（それらはすべて成分です）が、「動作」は異なります（たとえば、穀物がすりつぶされ、ホップ/酵母などに適用されないものに対処するロジックが存在するなど）。

成分が十分に異なるので、dbに3つの別個のテーブルを置くことだけを考えています...しかし、コントローラーについてはどうですか？単一の成分コントローラーを使用して個別のモデルを管理できますか？

私はSTIの代替（クラステーブルの継承、およびマルチテーブルの継承）について読みましたが、すべてのソリューションは扱いにくいようです。STIの便利さ（タイプに関係なく、単一のテーブルクエリですべての成分を取得するなど）の欠点がない（nullフィールド、サブクラスやフィールドを追加し続けると扱いにくいテーブルなど）代替手段はありますか？

申し訳ありませんが、この質問は少しあいまいですが、明確な解決策を見つけることができないように感じ、現在、どちらの方法がより悪が少ないかを理解しようとしています。他の人もこれに対処していると思います。さまざまなソリューションの長所と短所を聞きたいです。ありがとう！

永続的にnullのフィールドと扱いにくい大きなテーブルは概念的には見苦しくなりますが、通常、実際には実際に非効率になることはありません。nullフィールドが使用する余分なスペースは、ほとんどのシステムにとって重要な考慮事項ではありません。インデックスを適切に設定すれば、クエリ速度が遅くなることはありません。

また、STIの利点は多くの場合価値があります（結合を最小限に抑えることによるデータベースの効率化、および共有コードの単純さとDRYness）。したがって、従来のSQLシステムを使用する場合は、概念的な醜さを無視してSTIを使用することを学んでください。あなたのユースケースは、STIが設計されたものです。

とはいえ、このプロジェクトをデータベースシステムに接続するには、開発サイクルが深すぎず（そしてそうではないように思われる場合）、ある程度の時間を調査/学習に費やす気がある場合は、 SQLの代替を検討したい（そこに多くの良いものがあります）。現在最も人気のある代替手段（そして私の個人的なお気に入り）はMongoDBです。

MongoDBは、スキーマベースではなくドキュメントベースです。つまり、何を格納できるかについてはそれほど厳格ではありません。MongoDBには強制された構造化スキーマがないため、プロジェクトでは単一のコレクションを作成できますingredients（MongoDBの「コレクション」はSQLデータベースの「テーブル」に似ています）。ingredientこのコレクションのそれぞれは、Ingredientスーパークラスで定義された共有フィールドを持つことができます（これらのフィールドは、データベース自体では定義されません）。そして、サブクラスはMalt、HopsとYeast（いないデシベル自体に、これらのモデルのサブクラスで直接定義されているように、再び）自分自身の個別のフィールドを持つことができます。これはまさにあなたが探しているものです-それは概念的な醜さなしにSTIのすべての便利さを提供します。

追加のボーナス：このようなNoSQLデータベースシステムを使用すると、アプリの他の領域も同様に簡素化される場合があります。多くの（ほとんど？）一般的なWebビジネスドメインでは、SQLよりもNoSQLの方が適しています。これは、Webドメインは特にドキュメントを多用する傾向があるためです（ドキュメントはストレージメカニズムの自然な選択です）。

概要：管理またはアプリの一部がSQLデータベースに依存しているためにSQLデータベースを使用している場合、または何か新しいことを学ぶ時間がない場合は、STIを使用してください。SQLデータベースの使用に慣れておらず、何か新しいことを学ぶ時間がある場合は、MongoDBまたは別のドキュメントベースのNoSQLデータベースに切り替えることを強くお勧めします。