SQL：1つの外部キーが複数のテーブルのいずれかの主キーを参照します

Question

私は、他のアプリケーションの拡張可能なフレームワークとして使用されるアプリケーションに取り組んでいます。

基本クラスの1つはノードと呼ばれ、ノードにはコンテンツがあります。 SQLテーブルは次のようになります。

TABLEノード（NodeId int、....など）

TABLE NodeContentRelationship（NodeId int、ContentType string、ContentId int）

アプリケーションを拡張して独自のコンテンツタイプを作成するのは開発者次第です。

外部キー列であるにもかかわらず、NodeContentRelationship.ContentIdに外部キー関係を追加することはできないため、関係データベースの観点からは明らかにこれは悪いことです。

ただし、ソリューションは非常にシンプルで強力なので、変更するのをためらいます。

あなたはどう思いますか-私は道の痛みの世界にいますか？

Answer 1

NoteContentRelationship.ContentId を外部キーとして設定できないのはなぜですか？抽象基本クラスを表すテーブル Content と、派生を表すさまざまなテーブル AnimalContent 、 CarContent などで、リレーショナル継承モデルを簡単に使用できます。クラス。

Answer 2

内部プラットフォーム効果に注意してください。

開発者が異なる「コンテンツタイプ」のデータを保存し、それらを一般的な方法で相互に関連付けることができる「拡張可能なフレームワーク」を構築しようとしている場合、他のユーザーが既に解決済み this 問題。

Answer 3

これは、EAV（エンティティ、属性、値）設計のバリエーションのように見えます。

EAV設計の利点と欠点は広範囲に文書化されています。

これは、同情的な観点からのEAVの説明です。

http://ycmi.med.yale.edu /nadkarni/Introduction%20to%20EAV%20systems.htm

そして、これは敵対的な観点からのものです：

http：// tonyandrews .blogspot.com / 2004/10 / otlt-and-eav-two-big-design-mistakes.html

EAVのマイナス面に注意して、数千時間をかけてデータを注ぎ込んでください。プログラマーにとって非常に魅力的ですが、データマネージャーの悪夢になりかねません。

Answer 4

このデータを実際に報告したい場合、あなたは道を痛めつけています。結合などの記述が非常に難しくなりました。制約がないことは悪いことですが、クエリに必要な余分な作業は（IMHO）より悪いです。

ただし、他の開発者がシステムを拡張してデータベースにデータを保存できるようにしたいが、データベーススキーマを変更できないようにする場合は、選択肢がない場合があります。その場合の答えは、この方法で保存される量を最小限にすることです。また、ContentTypeを別のテーブルで定義されたContentTypeIdに置き換えることで、少し高速化することもできます。