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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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 

т.д.

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

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

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

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

Как об этом alt text http://www.freeimagehosting.net/uploads/8241ff5c76.png