私の同僚の 1 人がテーブル スキーマを設計しました。テーブルの 1 つで、列は別の列の値に応じて異なるテーブルの主キーを参照できます。私はそれが別様に間違っていることを知っていますが、私をサポートする理論を見つけることができません. 彼のスキーマは次のようになります。
table video: (id, name, ...)
table audio:(id, name, ...)
table review_item( item_type, item_id, reason, ...)
の場合item_type='V'、item_id はテーブル ビデオの ID であり、item_type='A'item_id はテーブル ビデオの ID です。
item_type( 、 )の組み合わせitem_idはユニークですが、実際にはまったく外部キーではありません。単一のテーブルを指していないため、外部キーとして定義することはできません。DDL 構文では許可されていません。
誰かがここで違反している原則または規則を見つけることができますか?
それは機能しますが、他の可能性のある間違いを指摘しています。より悪いデザインを考えることができました。完全性を強制することは大雑把です。
もちろん参加することもできますが、item_type によって制約するために「where」に追加の条件が必要です。
このタイプの配置は、オーディオとビデオのテーブルが 1 つのテーブルであり、他の列がオーディオ/ビデオ性を区別し、そのようなジャムに陥った場合にオーディオのみまたはビデオのみの情報に 1-1 リンクする必要があることを示している可能性があります。しかし、現実世界では同じ情報の多くが両方に当てはまるようです。実際、無声映画でない限り、ビデオ テーブルにすべてのオーディオ情報を含める必要はありません :-) ??? 1 つだけ当てはまる場合は、null を入れます。
oo-db を使えば簡単ですよね？j/k...
明らかに、それは間違っています。「単一責任の原則」に違反していると主張することができます。つまり、物には特定の明確な目的が必要です。ただし、例を挙げて、これがどのように悪いのかを明確にしてください（用語/フレーズを述べただけで十分であると期待しないでください）.
私が抱えている主な問題は、DBがそのような基準で外部キー制約を強制できるとは思わないことです(おそらく、いくつかのカスタムルールを介して可能です)。つまり、MS SQLでは、他のテーブルの主キーを参照してそれを強制することはできませんでした。整合性（つまり、制約の強制）がFKの主な利点の1つであることを考えると、これが私の主な議論になります。OR/Mapper の動作方法 (使用している場合) に応じて、これも取り上げます。それは彼がとった戦略をサポートしないかもしれません。
この状況で外部キーを適用 する方法の例を参照してください: http://consultingblogs.emc.com/davidportas/archive/2007/01/08/Distributed-Keys-and-Disjoint-Subtypes.aspx
item_type 列は第 2 正規形に違反していますが、次の理由から問題ないと思います: A) 異常が発生しないことを意味する CHECK 制約を簡単に実装できる、B) アイテムが存在できないという非常に有用な制約を強制するために支払う代償は小さい複数のタイプの。ほとんどの SQL DBMS では、型列を各テーブルにプッシュしない限り、その規則を宣言的に適用することはできません。