6

イベントと写真があり、両方のコメントがあります。現在、2 つのコメント テーブルがあります。1 つはイベントに関連するコメント用で、もう 1 つは写真のコメント用です。スキーマは次のようになります。

CREATE TABLE EventComments
(
  CommentId int,
  EventId int,
  Comment NVarChar(250),
  DateSubmitted datetime
)

CREATE TABLE PhotoComments
(
  CommentId int,
  PhotoId int,
  Comment NVarChar(250),
  DateSubmitted datetime
)

私の質問は、それらを組み合わせて、別の相互参照表を追加する必要があるかどうかですが、適切に行う方法が思いつきません。これでいいと思いますが、どう思いますか？

編集

ウォルターの答え（およびいくつかの軽い読書）に基づいて、私はこれを思いつきました：

CREATE TABLE Comments
(
  CommentId int,
  Comment NVarChar(250),
  DateSubmitted datetime
  CONTRAINT [PK_Comments] PRIMARY KEY
  (
    CommentId
  )
)

CREATE TABLE EventComments
(
  CommentId int,
  EventId int
)

CREAT TABLE PhotoComments
(
  CommentId int,
  PhotoId int
)

ALTER TABLE EventComments ADD CONSTRAINT FK_EventComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId)

ALTER TABLE PhotoComments ADD CONSTRAINT FK_PhotoComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId)

構造間に実際にパフォーマンスの違いはありますか? 私には、それは少し好みのようです。2 番目のスキーマには利点があります。イベントのコメントや写真のコメントに具体性を追加したい場合は、そのための別のテーブルがあり、両方で新しいプロパティを共有したい場合は、単一のテーブルがあります。新しいプロパティを追加します。

4

4 に答える 4

9

コメント、PhotoComments、およびEventCommentsは、「一般化スペシャライゼーション」と呼ばれるパターンで関連付けられています。このパターンは、オブジェクト指向言語の単純な継承によって処理されます。同じパターンをキャプチャするテーブルのスキーマを設定するのは少し複雑です。

しかし、それはよく理解されています。「一般化スペシャライゼーションリレーショナルモデリング」をグーグルですばやく検索すると、このテーマに関するいくつかの優れた記事が表示されます。

于 2009-09-25T16:13:23.690 に答える
4

それらを組み合わせると、キー構造が台無しになります。null 可能な外部キー、またはキーとタイプの「ソフト」キー構造が必要です。私はそれらを別々に保ちます。

于 2009-09-25T15:54:02.260 に答える
1

それらを組み合わせて、写真用かイベント用かを示すフィールドを追加できます。

2 つの外部キーが必要です。1 つは写真用、もう 1 つはイベント用ですが、それらを 1 つのテーブルにまとめることで、単一のコード セットを記述してすべてのコメントを処理できます。

しかし、私は引き裂かれています。同じリスト内で 2 つのコメント タイプを混在させる必要がない場合 (UNION が必要)、それらを別々に保持する方がクリーンです。

于 2009-09-25T15:52:07.070 に答える
1

私の個人的なデザイン スタイルは、それらを組み合わせてから、整数フラグを追加してコメントの目的を示すことです。これにより、後でさらに追加したい場合に備えて、スケーラビリティも得られます。

于 2009-09-25T15:53:05.053 に答える