Дизайн базы данных для многоцелевого использования Таблица

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

продукта, заказ, комментарий, ProductComment {ProductID, CommentID}, {OrderComment OrderID, CommentID}
продукта, заказ, ProductComment {ProductID, Text}, OrderComment {OrderID, текст}
продукта, Заказ, комментарий {ProductID, OrderID, текст}

Использование SQL Server 2008, кстати.

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

источник

2010-11-12 Josh M.

Взгляните на ** [аналогичный вопрос/ответ] (http://stackoverflow.com/questions/4050784/defining-multiple-foreign-keys-in-one-table-to-many-tables/4051523 # 4051523) **. –

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

источник

2010-11-12 05:11:06 theazureshadow

Согласовано о аспекте дублирования. Мне нравятся таблицы связывания, за исключением того, что мне не нравится дополнительный шаг, чтобы перейти к таблице комментариев. –

Да, связующий стол делает ваши запросы более сложными. Использование нескольких столбцов вместо этого также означает, что если вы получаете все комментарии, вы можете указать, какой комментарий они представляют, не делая никакого JOIN вообще, и если вы используете идентификаторы в URL-адресах (или других ссылках), вы можете просто напрямую связать на комментарий к комментарию. – theazureshadow

Еще одна причина, по которой мне нравится ссылка, заключается в том, что вы можете добавлять дополнительные поля по мере необходимости. Возможно, в таблице ProductComment также есть некоторые поля, которые строго связаны с этой комбинацией Product \ Comment. –

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

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

CommentID 
EntityID 
EntityType 
Comment

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

источник

2010-11-12 05:02:01

Спасибо. Причина, по которой я не перечислял этот параметр, заключается в том, что это нарушает внешние ключи. Я действительно не хочу проверять EntityType, чтобы определить, какую таблицу искать в Entity. –

У этого есть ограничение, в котором вы не можете использовать явные внешние ключи в базе данных, которая их поддерживает (например,InnoDB), что означает, что вы не можете использовать такие функции, как 'CASCADE'. Я ценю, что это уменьшает количество необходимых таблиц, и во многих случаях это хорошо, но это не повсеместно стоит того. – theazureshadow

@Josh Ницца, избили меня :) – theazureshadow

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

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

с ... 'S как дополнительный столбец для каждой примечательной таблицы.

источник

2010-11-12 05:36:14 SingleNegationElimination

Возможно, это может сработать, но ответчик - это то, как это обычно делается. – SingleNegationElimination

Это мой вариант №3. Не уверен, если мне это нравится, хотя .... Я склоняюсь к варианту 1. –

@TokenMacGuy Я думаю, что ответ знакомого хуже, чем 3 варианта, которые я перечислил. –

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

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

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

источник

2011-03-08 17:08:21

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

источник

2011-04-19 13:55:03 skaz

Спасибо за предложение, но я считаю, что это довольно грязный, не-OO способ структурирования базы данных. Вы теряете логику БД, чтобы проверить, существует ли сущность. Конечно, вы можете сделать это в коде, но с точки зрения БД это не очень чистое решение. –

@Josh M - Вам нужно будет рассмотреть вопрос о компромиссе. Не все может быть совершенным. Это очень простой способ делать вещи - сущность является полиморфной, поскольку она представляет множество разных типов в одной таблице. – skaz

Дизайн базы данных для многоцелевого использования Таблица

ответ

Смежные вопросы