Принадлежит к лучшим практикам взаимоотношений db?

Question

Я работаю над сайтом фотографии. Фотографии на сайте всегда будут принадлежать ровно одному событию. Мой первоначальный дизайн был:

Table: Events 
ID, Title, etc 

Table: Photos 
ID, ThumbnailURL, etc 

Table: EventPhotos 
EventID, PhotoID, SortOrder 

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

Table: Events 
ID, Title, etc 

Table: Photos 
ID, EventID, SortOrder, ThumbnailURL, etc 

Кажется, вид грязной/запутанна, чтобы мне, что данные отношения событие в таблице фото - оригинальный дизайн отделяет фотографию, событие и отношения, но он избегает объединения, и это заставляет соотношение «иметь один/принадлежит» вместо «имеет много» - что вы думаете?

Answer 1

Для отношения «один-ко-многим» ваш второй прием - это стандартный, нормальный, правильный способ его выполнения.

Тем не менее, вы полностью уверены, что отношения «многие-ко-многим», которые вы наброскали при первом взятии, не применимы? Я не был бы так уверен, но вы знаете свой домен лучше, чем I.

EDIT:

ОП добавил комментарий;

Спасибо. Я действительно не верю, что фотографии должны принадлежать более чем одному событию - события - это фотосессии, каждая фотография по определению от определенной съемки, а просмотр по событию - единственный способ просмотреть сайт. Я уверен, что один-ко-многим правильный.

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

Наблюдение 1. Самое главное, что вы не можете моделировать схему, не зная двух вещей: моделирование реальной проблемной области, и, что требует наше решение от модели.

Мое первоначальное предположение состояло в том, что события и изображения OP моделировали дисплей фотографий на мероприятиях, например, в картинной галерее (или в галерее изображений на веб-сайте). В этом случае, например, в галерее Ansel Adams Online могут быть очень интересные события, на которых показаны фотографии Ансела Адамса под названием «Зрелая работа Адамса», «Фотографии структур Адамса» или «Фотографии пустынь Адамса». Все три события могут включать в себя Адам "Transmission Lines in the Mohave Desert", 1941. Поскольку многие фотографии могут отображаться во многих событиях, нам нужна структура «многие-ко-многим».

Но «событие» OP - это фотосессия, и, очевидно, как отмечает OP, любая фотография снимается в одной и единственной фотографии.

Урок здесь состоит в том, что мы не можем моделировать (или моделировать только временно), пока не узнаем Проблемную область.

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

Наблюдение 2. Комментарий ФП дает ответ на его возражение о том, что наличие события FK на фотографии является «грязным». OP довольно уверенно понимает, что это «избегает объединения, и это заставляет отношение к« имеет один/принадлежит », а не« имеет много ». (Избегая объединения - проблема реализации, правильная взаимосвязь более фундаментальна, так как это вопрос моделирования).

Что он должен также понимать, так это то, что в нашем решении и в Проблемном домене имеет смысл спросить фотографии, «на какой фотосессии/мероприятии была сделана эта фотография». И вот почему это не грязно: «в котором сеанс принят» является законным вопросом или атрибутом фотографии, и FK дает ответ на этот вопрос. Это также означает, что в этом случае FK от фотографии к событию не должен " t быть недействительным: фотография должна иметь фотосессию, иначе фотографии не может быть.

(Здесь есть несколько дополнительных уроков, о том, что значит иметь отношения aa one-to-many или много-ко-многим, и что это означает, чтобы сделать FK нулевым или нет, я оставлю это в другое время.)

Answer 2

Я не могу сказать, что я когда-либо был склонен использовать ваш первый вариант для чего-то подобного. Я бы пошел со вторым. Будет использоваться меньше запросов. Просто сортировка вашего запроса с помощью SortOrder будет работать отлично.

Добавлено: Единственная причина, по которой я буду использовать первую, - это, если бы вы (по крайней мере, в какой-то момент) хотели сделать так, чтобы фотографии могли быть добавлены в несколько альбомов, что, похоже, не так ,

Answer 3

Я голосую за второе взятие. Нет необходимости иметь отдельный eventphotos Таблица

Answer 4

Тогда у вас второй дизайн, самый чистый. С первым дизайном вы можете использовать «имеет одну» связь между таблицами «Фотографии» и «EventPhotos», но у них нет никакого смысла выделять их таким образом. Если в будущем вы считаете, что вам нужны отношения «многие ко многим», то только на этом этапе измените дизайн на оригинал.

Cheers, Gra.

Answer 5

Любой способ, которым оба проекта будут вызывать отношение «один ко многим», только адреналин, который вы получите во втором, означало еще одно объединение. Но, учитывая хороший дизайн БД, я предпочту первый. Вы можете так думать, если только таблица фотографий нуждается в связи с другими таблицами, на этот раз ваш eventID в этой таблице не имеет никакой роли.

For samll level db design i would prefer 2 but for large or medium scale i would prefer the first. 

Answer 6

Я согласен с другими, которые указывают ваш второй вариант является приемлемым способом для реализации один-ко-многим (одно событие, много фотографий). Объектно-ориентированный фон заставит вас почувствовать, что наличие столбца внешнего ключа события в таблице фотографий является неудобной связью двух отдельных объектов. Но с точки зрения реляционной базы данных так оно и делается.

Единственный способ сохранить свой первый выбор при одновременном предотвращении использования фотографии для нескольких событий - это установить уникальное ограничение на столбец PhotoID EventPhotos. Тогда отношения между EventPhotos и Photos станут взаимно однозначными, что беспредметно, но вы получите развязку фотографий и событий.

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