3

現在、複数の画像/動画URLを持つオブジェクトを保存するための次の設計があります。

tblCompany:
pkCompanyId

tblPerson:
pkPersonId

tblImage:
pkImageId
ImageUrl
fkCompanyId
fkPersonId

このデザインは以下を処理しますが：

  1. 複数の画像を持っている会社
  2. 複数の画像を持っている人

tblImageの行には、外部キー列に大量のNULL値が含まれるため、この設計に問題があると感じずにはいられません。

より良いデザインはありますか？デザイン内のより多くのオブジェクト（会社または個人に関連しないもの、会社または個人に関連するもの）には画像が含まれるため、現在の設計ではtblImageに外部キーが増える可能性があります。

4

2 に答える 2

3

これは、実際には、画像を持つことができるエンティティが 2 つだけの非常に優れた設計です。はい、多くの NULL がありますが、代替 (個別のイメージ テーブルや特別に作成された 1:N リンク テーブルなど) にも問題があります。

これは 1:N の関係であるため、追加の M:N ジャンクション/リンク テーブルは必要ありません。

画像を持つことができるより多くの種類のエンティティを追加する必要がある場合は、次のように継承を検討できます。

ここに画像の説明を入力

tblCommonこのようにして、エンティティの種類に関係なく、イメージは から継承する任意のエンティティに自動的に接続できます。残念ながら、継承はリレーショナル DBMS では直接サポートされていないため、3 つの方法のいずれかで継承をエミュレートする必要がありますが、それぞれに独自の妥協点があります。

于 2012-09-18T11:12:00.960 に答える
1

スキーマを正しく理解していれば、Company と Person は無関係であり、どちらも 1 つ以上の画像を持つことができます。次に、画像自体のテーブルと、会社から画像へのマッピングおよび個人から画像へのマッピング用の 2 つの異なるテーブルを作成できます。

tblCompany: pkCompanyId
tblPerson: pkPersonId    
tblImage: pkImageId ImageUrl    
tblPersonImage: fkImageId fkPersonId    
tblCompanyImage: fkImageId fkCompanyId

このスキーマを使用すると、将来的にイメージを他の種類のエンティティ (製品など) に関連付けることもできます。

于 2012-09-18T10:01:43.193 に答える