A、B、C の 3 つのテーブルがあります。テーブル A は、B および C と (n:1) 関係にあります。通常、A には B.Id (または C.Id) とテーブル名を格納します。
例えば
A.ParentId = 1
A.TableName = "B"
A.ParentId = 1
A.TableName = "C"
A.ParentId = 2
A.TableName = "B"
それは良い解決策ですか?他の解決策はありますか?
A、B、C の 3 つのテーブルがあります。テーブル A は、B および C と (n:1) 関係にあります。通常、A には B.Id (または C.Id) とテーブル名を格納します。
例えば
A.ParentId = 1
A.TableName = "B"
A.ParentId = 1
A.TableName = "C"
A.ParentId = 2
A.TableName = "B"
それは良い解決策ですか?他の解決策はありますか?
なぜ2つのparentid列ではないのですか?
A.ParentIdB = 1
A.ParentIdC = 3
もう 1 つの可能性は、投稿と画像の「スーパータイプ」として機能する別のテーブル Content (D) を導入することです。次に、コメント (A) の行は、投稿 (B) および画像 (D) の各行と同様に、コンテンツの主キーを参照します。投稿と画像の共通フィールドはコンテンツ (おそらく「タイトル」または「日付」) に移動され、元のテーブルには投稿または画像に固有の情報 (おそらく「本文」または「解像度」) のみが含まれます。これにより、フィールドにテーブル名を含めるよりも結合を実行する方が簡単になりますが、実際のエンティティが投稿とコメントの両方になる可能性があることを意味します (実際には、投稿またはコメントを乗算することもできます!)。ただし、実際には、モデル化しようとしている状況によって異なります。