DBは次のように設計されている場合：データベースの設計上の問題
Table A
a (type x)
a is (PK)
Table B
a (type x)
a is (PK)
Table C
a (type x)
a is (FK) references A(a)
a is (FK) references B(a)
は、この正しい設計ですか？そうでない場合、このケースのための最良のデザインは何ですか？
私はCは、例えば、AまたはB
の子で
Aである場合は、ページ
Bは写真
で、可能性がどこに参照している状況があると信じてCはコメントです
Cは、画像やコメント用のコメントです。この場合
私はあなたが、アプリケーション側からのデータの整合性をimplimentする必要があります
Table C:
a (type x)
b (type CHAR) //<- defines which table a is the key of
INDEX(b,a)
SQL = SELECT * from C where b = TABLE_A_name and C.a = A.a
or
SQL = SELECT * from C where b = TABLE_B_name AND C.a = B.a
を次のように二重の鍵であるためにCを調整します。
したがって、外部キーの実装とデータの完全性の面では、あまりにもファジーな設計です。問題は、アプリケーション機能が混乱の価値があるかどうか、そしてそれがうまく管理された環境にあるかどうかです。
+0。それは、彼/彼女がしようとしているものかもしれないが、どうやって知っているだろうか？ ：/ –
私がすべての状況で知っているのを待っていたら、決して何もしません。 この特定のテクニックは私のために驚異をもたらしました。私は何が助けになるかを分かち合っています。そして、正直言って、彼/彼女が行っていることになるかもしれません。 –
これは、一連の問題の正しい設計であるStar Schema Designと呼ばれるものです。あなたが問題を定義していない限り、それが良い設計かどうかをあなたに伝えることはできません。
-1。スター・スキーマでは、ファクト表Cに2つの独立したフィールドがあります.1つはFKとA、もう1つはFKからBです。この設計では、AとBの両方にFKを持つフィールドは1つだけです。 –
あなたは正しいです、彼が最初に（そして2番目の）それを読んで指定した方法は、彼は2つの別々のフィールドを持っていたようだ。 –
はい、それは確かに珍しいデザインです。:) –
したがって、表BおよびAに対応する行が存在する場合にのみ、表Cに行を挿入できます。行のID値は同じでなければなりません。なぜ表AとBをマージしないのですか？表Cの表Bのfkを削除するか、表Bの表Aへの参照を追加してください。私はこの設計をどのように達成したいのかは完全にはわかりませんが。
は、3者関係のようです。 A、B、Cが何であるか分からなければ、あなたは「正しい」デザインを持っているかどうかを知ることは不可能です。
-1。そうではないにしても、3元（多対多）の関係では、Cには2つの独立したフィールドが必要です（FKとA、BとFKの2つのフィールドを持つ必要があります） B. –
おっと、そうです、私はスキーマを読んでいません。私はテーブルCが3つのフィールドを持っていると思った。 – JMM
@JMM：やりやすい質問者が実際にこの取り決めで何をしようとしているのか、私は考えることができません... –
このデザインで何を達成しようとしているのか、使用しているDBMSの種類を含めることができますか？ –
テーブルCにAとBの両方のFKである単一フィールドがあることを意味しますか？ –