多様なアソシエーションは、悪いデータベースデザインとみなされます。参照整合性がなくなるように、多形ID列に外部キーを持つことはできません。Polymorphic Associationsの代わりに何を使用しますか？
また、のサブタイプでは動作が異なる場合を除き、STIは不良品と見なされます（）。
私は私のユーザーは、エンティティの複数の種類の手順のコレクションを作成できるようにする必要があります。
だから私の質問は、次のシナリオではより少ない悪が何であるかのRails/ActiveRecordのためです。ポリモーフィック団体にスキーマを使用して
はこのようなものになります。私の作品は、データに異なる（とないので、
-- collections
id, name, ...
-- exhibits
id, collection_id, artwork_id, position
-- artworks
id, type, <photograph columns>, <film columns>, <painting columns>, etc.
しかし：
-- collections
id, name, ...
-- exhibits
id, collection_id, exhibitable_type, exhibitable_id, position
-- photographs
id, ...
-- films
id, ...
-- paintings
id, ...
-- songs
id, ...
-- sculptures
id, ...
を私はSTIを使用して、このようなものを持っている可能性がありちょうど動作）、私は今アートワークの表の上にNULLを持っています。私は以前にそこには存在しなかったオブジェクトに継承階層を導入しました。特にデータベース設計に役立つ唯一の目的がある場合、私は一般的に慎重です。
STIは少なくともクエリとコード化が簡単であるようです。
これは、それほど悪いことではありませんか？
はその後、他のオプションは、マルチテーブル継承である：
-- collections
id, name, ...
-- exhibits
id, collection_id, artwork_id, position
-- artworks
id
-- photographs
artwork_id, <photograph columns>
-- films
artwork_id, <film columns>
これは、STIのNULLの問題を取り除くだろうともダウンサイズのテーブルを保持します。厳密に必要とは思わないオブジェクト階層がまだあります。しかし、私の目で最大の問題は：Railsはそれをサポートしていないことです。 CITIERの宝石はとても素敵に見えますが、最近のコミットがありますが、広く使われているわけではありませんので、私のアプリの基礎でそれを使用するのは慎重です。 SequelやCTIをサポートしている別のORMを使うこともできます。
真実は私がマルチテーブル継承私は位置列を必要としなかった場合、私は単にcollections_photographsのように別々のテーブル結合を使用することになり
最善の解決策、collections_paintings、collections_filmsなどが、私が好きだと思う言われます手動で注文する必要があります。
だから、オプションがあるようだ：
- PA：参照整合性の喪失（？常にデータベース・アクセスのためのActiveRecordを使用している場合、それは実際には関係ない）
- STI：ヌルのたくさんの大きなテーブル
- CTI/MTI：小さい悪であり、任意の他のオプションがあり、広く
を使用していない宝石に頼りますか？私はPostgresを使用しています。