Поля базы данных типа идентификатора владельца

Question

Предположим, у вас есть эти таблицы: RestaurantChains, Restaurants, MenuItems - с очевидными отношениями между ними. Теперь у вас есть таблицы Comments и Ratings, в которых хранятся комментарии / оценки клиентов о сетях, ресторанах и пунктах меню. Как лучше всего связать эти таблицы? Очевидные решения могут быть:

• Используйте столбцы OwnerType и OwnerID в таблицах Comments и Ratings, но теперь я не могу добавить внешние ключи для связи комментариев / оценок с объектами, для которых они предназначены
• Создайте отдельные таблицы Comments и Ratings для каждой таблицы, например, MenuItemRatings, MenuItemComments и т. Д. Преимущество этого решения состоит в том, что присутствуют все правильные внешние ключи, и имеет очевидное неудобство, так как имеет множество и множество таблиц с практически одинаковой структурой.

Итак, какое решение работает лучше? Или есть даже лучшее решение, о котором я не знаю?

Answer 1

Поскольку комментарии о пункте меню отличаются от комментариев о ресторане (даже если они имеют одинаковую структуру), я бы поместил их в отдельные таблицы и имел соответствующие FK для обеспечения некоторой целостности данных в вашей базе данных.

Я не знаю, почему существует отвращение к наличию большего количества таблиц в вашей базе данных. Если вы не перейдете от 50 таблиц к 50000 таблицам, вы не увидите проблем с производительностью из-за больших таблиц каталога (а наличие большего количества таблиц меньшего размера в этом случае должно фактически повысить производительность). Я также склонен думать, что было бы намного яснее понять при работе с таблицами под названием «Menu_Item_Comments» и «Restaurant_Comments», чем с таблицей под названием «Комментарии» и не зная, что именно в нем находится имя его.

Answer 2

Как насчет этого альтернативный текст http://www.freeimagehosting.net/uploads/8241ff5c76.png

Answer 3

Используйте одну таблицу для комментариев и используйте GUID в качестве первичных ключей для ваших энтитов.

Затем вы можете выбирать комментарии, даже не зная заранее, где они принадлежат:

SELECT CommentText
FROM Comments c, Restaurants r
WHERE c.Source = r.Id

SELECT CommentText
FROM Comments c, Chains ch
WHERE c.Source = ch.Id

и т.д.

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

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

Вы также можете создать глобальную таблицу Entity (с одним столбцом GUID), чтобы ваши Chains, Restaurants, MenuItems и Comments ссылались на эту таблицу с FOREING KEY ON DELETE CASCADE, и когда DELETE, скажем, в ресторане, удалите его из этого стола. Он удалит как ресторан, так и все комментарии к нему, и вы сохраните свою целостность.

Answer 4

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

например. для ресторанов и комментарии:

Restaurants
  id (PK)
  (attributes of restaurants...)

RestaurantComments
  id (PK)
  restaurantid (FK to Restaurants)
  commentid (FK to Comments)

Comments
  id (PK)
  (attributes of comments...)

Answer 5

Иметь единую таблицу комментариев / рейтинга для всех объектов и не использовать автоматически генерируемые внешние ключи. Ключ в таблице рейтингов, например, RatingID, можно поместить в поле в таблице Restaurant, Chain, Menuitems, и все они могут указывать на одну и ту же таблицу, они все еще являются внешними ключами.

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