私は、他のアプリケーションの拡張可能なフレームワークとして使用されるアプリケーションに取り組んでいます。
基本クラスの 1 つは Node と呼ばれ、Node には Content があります。SQL テーブルは次のようになります。
TABLE Node ( NodeId int, .... など )
TABLE NodeContentRelationship ( NodeId int, ContentType 文字列, ContentId int)
アプリケーションを拡張して独自のコンテンツ タイプを作成するのは開発者次第です。
外部キー列であってもNodeContentRelationship.ContentId に外部キー関係を追加することはできないため、これは関係データベースの観点から明らかに悪いことです。
ただし、ソリューションは非常にシンプルで強力なので、変更するのは気が進まない.
あなたはどう思いますか？
インナープラットフォーム効果に注意してください。
開発者がさまざまな「コンテンツ タイプ」のデータを保存し、それらを一般的な方法で相互に関連付けることができる「拡張可能なフレームワーク」を構築しようとしている場合、他の人がすでにこの問題を解決 していることに気付くかもしれません。
NoteContentRelationship.ContentId外部キーとして設定できないのはなぜですか? Contentリレーショナル継承モデルは、抽象基本クラスを表すテーブルと、派生クラスを表すさまざまなテーブルAnimalContent、などで簡単に使用できます。CarContent
これは、EAV (エンティティ、属性、値) 設計のバリエーションのように見えます。
EAV 設計の利点と欠点は、広く文書化されています。
以下は、同情的な観点からの EAV の説明です。
http://ycmi.med.yale.edu/nadkarni/Introduction%20to%20EAV%20systems.htm
そして、これは敵対的な観点からの1つです：
http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html
EAV にデータを流し込むために何千時間もの工数を投入する前に、EAV のマイナス面に注意してください。プログラマーにとっては非常に魅力的ですが、データ管理者にとっては悪夢になる可能性があります。
このデータについて実際に報告したい場合は、将来的には傷ついた世界にいます。結合などを作成するのがはるかに難しくなりました。制約の欠如は悪いことですが、クエリに必要な余分な作業は（IMHO）さらに悪いです。
ただし、他の開発者がシステムを拡張してデータベースにデータを格納できるようにしたいが、データベーススキーマを変更できないようにしたい場合は、選択の余地がない可能性があります。その場合、答えは、この方法で保存される量を最小限に抑えることです。ContentTypeを別のテーブルで定義されたContentTypeIdに置き換えることで、少しスピードアップすることもできます。