Является ли использование 1: n + n: 1 между одинаковыми таблицами плохим дизайном?

Question

Представьте себе, что таблица 1 «Событие» содержит информацию о событии, но вы хотите дать пользователям возможность отмечать одну дату из нескольких выбранных (поскольку существует несколько мнений о том, какая дата является правильной).Таким образом, даты на самом деле будут храниться в таблице 2 «Событие».

Конечно, между таблицами «Событие» и «Дата» должно быть отношение: 1, поэтому возможны несколько дат для каждого события.Но рекомендуется ли также добавлять отношение «1: n» из «Событие» в «Дата», чтобы сохранить текущую выбранную дату для этой записи «Событие»?

Очевидно, что альтернативой может быть сохранение флагав таблице «Дата» («Выбрано»), но я думаю, что это было бы не так быстро для доступа на чтение в таблице «Событие».Особенно в LINQ2SQL было бы действительно легко получить доступ к информации о дате, если есть отношение 1: n.

(я не хочу дополнительно сохранять фактические «выбранные» значения даты в таблице «Событие»).из-за технического обслуживания - вам придется обрабатывать его вручную, если выбрана другая «предпочтительная» дата и имеется около 6 полей даты для обработки всех видов информации о дате)

Answer 1

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

Нет, это неплохая идея, и ваши требования могут быть легко представлены только первичными и внешними ключами. Это проблема, которая встречается довольно часто, когда у вас есть отношение 1: n между родительской и дочерней таблицей, но есть требование, чтобы у вас был один дочерний элемент с определенным атрибутом. Например, многие системы CRM допускают использование нескольких адресов на одного клиента, но в качестве основного адреса можно определить только один адрес.

Самый простой сценарий таков:

Event
------------
EventID
...etc.
Primary Key (EventID)

EventDate
-----------
EventID
Date
Primary Key (EventID, Date)
Foreign Key (EventID) references Event (EventID)

Затем, как только эти таблицы существуют, добавьте в Event столбец SelectedDate со значением NULL и установите ограничение внешнего ключа для Event, который ссылается на EventDate с использованием EventID и SelectedDate

Answer 2

Что касается модели данных, то она не является «плохой» или неправильной, если это точное описание реальности, которую вы пытаетесь представить. К сожалению, в СУБД SQL возникают проблемы с применением таких циклических ограничений. Чтобы сделать это в SQL, вам обычно приходится идти на компромисс - обычно путем создания дополнительной таблицы для представления взаимосвязи между событием и датой.

Answer 3

Вы можете (или не можете) накладывать уникальное ограничение на UserID, EventID в таблице UserSchedule.

Answer 4

Да, это плохой дизайн. Вместо этого у вас должна быть таблица событий, таблица дат и таблица отображения m: n.