Дизайн базы данных с Entity Framework 4 - куда мне поместить мои внешние ключи?

Question

Я занимаюсь разработкой нескольких сайтов для просмотра медиа (видеоигры, телешоу, фильмы), и у меня возникла проблема с проектированием отношений между моими данными. Показательный пример:

Я решил, что наличие основной таблицы содержимого будет хорошей идеей для большинства данных. Мои таблицы «Статьи», «Новости» и «Обзоры» могут указывать на таблицу «Содержимое». Моя текущая настройка:

Содержание:

• ContentID - int, первичный ключ, идентификатор
• Текст - текст
• Дата добавления - дата и время

Оценка:

• ReviewID - int, первичный ключ, идентификатор
• Оценка - smallint
• ContentID - int, внешний ключ, который указывает на Content.ContentID

Игры:

• GameID - int, первичный ключ, личность
• Заголовок - nvarchar (50)
• GenreID - int, внешний ключ, указывающий на Genres.GenreID
• ReviewID - int, внешний ключ, который указывает на Reviews.ReviewID

Меня немного сбивает с толку, потому что Модель сущности показывает отношение «один ко многим» между Контентом и Обзорами, а также между Играми и Обзорами, когда они действительно должны быть один к одному. Каждый обзор должен указывать на одну запись контента, каждая игра должна иметь обзор, и на игру должен быть только один обзор.

Мне просто интересно, нахожусь ли я на правильном пути.

Answer 1

EF правильно, потому что ваша модель позволяет нескольким Обзорам совместно использовать один и тот же Контент, а нескольким Играм - один и тот же Обзор.

В то же время ваша модель логична, поэтому я не буду беспокоиться о том, что думает EF. Вы должны быть в состоянии удалить «Свойства навигации», которые вам не нужны, т.е. вы хотите удалить свойство Reviews в сущности Content (в конструкторе). Это не принесет вам никакой пользы, но может упростить вам задачу.

Если вы уверены, что у каждой рецензии должен быть свой собственный контент и т. Д., Вы должны сделать ContentID уникальным в таблице рецензий. Также не следует делать ContentID первичным ключом таблицы обзора - таким образом, обзор становится расширением контента. Однако вам нужно подумать, соответствует ли это вашим потребностям.

Answer 2

Для чего нужно поле Text в Контенте? Я бы переименовал его в нечто более описательное.

Это хороший дизайн базы данных, но более гибкий, чем ваши потребности. Единственное изменение, которое я хотел бы сделать, это сделать GameId не идентификатором, а переименовать его в ContentId и сделать его FK в таблице содержимого, чтобы вы могли одновременно искать игры / неигры , После этого я удалил бы столбец ReviewId из таблицы «Игры» (необязательно, поскольку вы можете присоединиться к полю Reviews.ContentId).

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