Когда две таблицы очень похожи, когда их следует комбинировать?

У меня есть события и фотографии, а затем комментарии для обоих. Прямо сейчас, у меня есть две таблицы комментариев, одна для комментариев, связанных с событиями, и другая для комментариев к фотографии. Схема похожа на это:

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)

Существуют ли какие-либо различия в производительности между структурами? Для меня это кажется немного предпочтительным. Я вижу преимущества во второй схеме, если я хочу добавить некоторую специфику к комментариям к событиям или комментариям к фотографии, у меня есть отдельная таблица, чтобы сделать это, и если я хочу, чтобы оба они делили новое свойство, есть одна таблица для добавьте новое свойство.

Ответы

Ответ 1

Комментарии, PhotoComments и EventComments связаны с шаблоном, называемым "специализация обобщения". Этот шаблон обрабатывается простым наследованием в объектно-ориентированных языках. Немного сложнее настроить схему таблиц, которые будут захватывать один и тот же шаблон.

Но это хорошо понято. Быстрый поиск в Google по "реляционному моделированию специализации обобщения" даст вам несколько хороших статей по этому вопросу.

Ответ 2

Если вы их объедините, это испортит ключевую структуру. Вам придется иметь нулевые внешние ключи или "мягкую" ключевую структуру ключа и типа. Я бы сохранил их отдельно.

Ответ 3

Вы можете объединить их и добавить поле, которое указывает, будет ли оно для фотографии или события.

Вам понадобятся два внешних ключа; один для фотографий и один для событий, но наличие их в одной таблице позволяет вам написать один набор кодов для обработки всех комментариев.

Но я разорван. Это чище, если вы держите их отдельно, при условии, что вам никогда не придется смешивать два типа комментариев в одном списке (для чего потребуется UNION).

Ответ 4

Мой собственный стиль оформления должен был объединить их, а затем добавить целочисленный флаг, чтобы сообщить, для чего нужен комментарий. Это также даст мне масштабируемость, если я захочу добавить более позднее.