Дизайн базы данных для многоцелевой таблицы

Question

Скажем, у вас есть несколько «вещей», к которым можно прикрепить один или несколько комментариев. Продукт и заказ, например. Как должны быть структурированы таблицы ....

1. Product, Order, Comment, ProductComment {ProductID, CommentID}, OrderComment {OrderID, CommentID}
2. Product, Order, ProductComment {ProductID, Text}, OrderComment {OrderID, Text}
3. Product, Order, Comment {ProductID, OrderID, Text}

Кстати, используя SQL Server 2008.

Мысли, мнения?

Answer 1

Я думаю, что Order/Product таблицы должны оставаться как есть.

Таблица Comments может быть

CommentID
EntityID
EntityType
Comment

Где EntityType скажет вам, к какой таблице принадлежит EntityID (ProductID/OrderID)

Answer 2

Определенно используйте только одну таблицу комментариев, поэтому вам не нужно дублировать информацию комментариев (например, отметку времени, flagged_for_moderation и т. Д.). Замечательно иметь два поля в комментариях, потому что ясно, что это ссылка «один ко многим». Я бы, вероятно, склонялся к этому над несколькими таблицами ссылок, хотя я действительно ценю, что у вас есть только строки в таблице ссылок, когда есть ссылка, в отличие от половины значений, равной NULL. Возможно, в очень большой базе данных с большим количеством комментариев, которые вы можете прокомментировать, вы можете использовать таблицы связывания.

Answer 3

Я фанат добавления идентификатора сущности и столбцов типа сущности, чтобы добавить гибкость без дополнительного соединения.

Answer 4

Если вы используете связывающие таблицы и у вас есть более 2 или 3 «типов», которые можно связать с комментарием, тогда подумайте о сгенерированном коде для создания всего необходимого вам SQL. Очень скоро у вас будет 101 связывающая таблица и множество SQL для определения таблиц для обслуживания.

Если вы используете GUIDS для всех своих идентификаторов и не хотите, чтобы внешние ключи определялись в базе данных, тогда есть другие варианты, но я не думаю, что стиль схемы базы данных у вас есть.

Это один из вариантов использования, который заставляет меня думать, что реляционная модель - это боль в шее!

Answer 5

Если вам не нравится метод entityID, entityType, поскольку вы не можете использовать ограничения внешнего ключа, вы можете выбрать смешанную стратегию, например,

COMMENT(commentID, comment, productID, orderID, ....)

с помощью ... в качестве дополнительного столбца для каждой комментируемой таблицы.