Для нескольких таблиц требуется одно-много отношений

У меня есть база данных SQL с несколькими таблицами: A, B, C, D. Объекты в этих таблицах - это совершенно разные вещи, с разными столбцами и разными типами отношений между ними.
Однако все они имеют одну небольшую вещь: необходимость в системе комментариев, которая в этом случае будет иметь идентичную структуру: author_id, date, content и т.д.

Интересно, какая стратегия лучше всего подходит для этой схемы, чтобы таблицы A,.. D использовали систему комментариев. На классическом веб-сайте "блог" я бы использовал отношение "один ко многим" с post_id внутри таблицы "комментариев".

Здесь, похоже, мне нужны таблицы A_comments, B_comments и т.д. Для решения этой проблемы, что выглядит немного странно.

Есть ли способ лучше?

ОТВЕТЫ

Ответ 1

Создайте таблицу comment с основным ключом comment_id и различными атрибутами комментария.

Кроме того, создайте A_comment таким образом:

CREATE TABLE A_comment (
    comment_id PRIMARY KEY REFERENCES comment(comment_id),
    A_id REFERENCES A(A_id)
)

Аналогично для B, C и D. Это обеспечивает ссылочную целостность между comment и всеми другими таблицами, которые вы не можете сделать, если вы храните идентификаторы до A, B, C и D непосредственно в comment.

Объявление A_comment.comment_id в качестве первичного ключа гарантирует, что комментарий может принадлежать только одной записи в A. Это не препятствует тому, чтобы комментарий принадлежал записи в и записи в B, но там только так много вас можно добиться с помощью внешних ключей; для этого потребуются ограничения на уровне базы данных, о которых ни одна база данных, о которой я знаю, не поддерживает.

Этот дизайн также не мешает сиротским комментариям, но я не могу думать о том, чтобы предотвратить это в SQL, за исключением, конечно, того, что вы хотели избежать: создать несколько таблиц комментариев.

Ответ 2

У меня была аналогичная "проблема" с комментариями для более разных типов объектов (например, статей и магазинов в моем случае, у каждого типа есть своя таблица).

Что я сделал: в моей таблице комментариев у меня есть два столбца, которые управляют связыванием:

  • object_type (тип ENUM), который определяет объект/таблицу, к которой мы привязываемся, и
  • object_id (беззнаковый целочисленный тип, который соответствует первичному ключу ваших других таблиц (или самому большому из них)), которые указывают на точную строку в конкретной таблице.

Структура столбца: id, object_type, object_id, author_id, date, content и т.д.

Здесь важно иметь индекс для обоих столбцов (object_type, object_id), чтобы быстро индексировать.

Ответ 3

Я предполагаю, что вы говорите о одной таблице комментариев с внешним ключом, чтобы "точно один из" A "," B "," C "или" D ".

Тот факт, что SQL не может справиться с этим, является одной из его основных недостатков. Вопрос задается снова и снова.

См., например.

Каков наилучший способ принудительного применения отношения подмножества с ограничениями целостности

Ваше ограничение - это "внешний ключ" из вашей таблицы "одиночных комментариев" в представлении, который является объединением идентификаторов в A, B, C и D. SQL поддерживает только внешние ключи в базовые таблицы.

Обратите внимание, что SQL как язык поддерживает вашу ситуацию в форме CREATE ASSERTION. Однако я не знаю, какие продукты SQL поддерживают этот оператор.

ИЗМЕНИТЬ Вы также должны иметь в виду, что с помощью таблицы "одиночных" комментариев вам может потребоваться принудительная дизъюнкция между ключами в A, B, C и D, иначе может произойти некоторое время, когда комментарий автоматически получает "общий" между сущностью вхождения из разных таблиц, что может быть нежелательно.

Ответ 4

У вас может быть одна таблица комментариев и внутри этой таблицы есть столбец, который содержит значение, отличающее ту, к которой принадлежит комментарий, - то есть 1 в этом столбце означает комментарий для таблицы A, 2 для таблицы B и т.д. на. Если вы не хотите иметь "магические числа" в таблице комментариев, у вас может быть другая таблица с двумя столбцами: одна с номером и другая подробная информация, какая таблица представляет собой номер.

Ответ 5

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