Организация схемы БД

Question

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

Справочная информация: Есть календарь событий, и любой пользователь в любое время может зарегистрироваться для любого из событий. Позже, но до этого события, один из администраторов войдет и выберет «Список персонала» из зарегистрированных, а остальные будут внесены в «Альтернативный список».

До сих пор я думал о том, что будет таблица событий, таблица пользователей, а затем еще три:

• UserEvent
  • Сопоставляет пользователей с событиями, на которые они зарегистрированы. Не подразумевает ни состава персонала, ни членства в списке Alt.
• UserStaff
  • Сопоставляет пользователей с событиями, на которые они зарегистрированы, а также с персоналом.
• UserAlt
  • Похож на UserStaff

Тогда вопрос состоит из двух частей:

• Это хороший способ сделать это?
• Должна ли каждая из этих трех ассоциативных таблиц иметь идентификатор пользователя и идентификатор события?

Этот второй вопрос действительно тот, который я бы хотел обсудить. Кажется, что это много дублированного материала (все в UserStaff или UserAlt всегда будет в UserEvent), поэтому я думал о создании уникального ключа для таблицы UserEvent, в дополнение к составному ключу, что другие таблицы (UserStaff и UserAlt) будет ссылаться на. С другой стороны, дублированного контента меньше, с другой стороны - промежуточная таблица (UserEvent), на которую нужно ссылаться практически в каждом запросе.

Надеюсь, я был достаточно ясен, и заранее спасибо.

Answer 1

У меня были бы следующие таблицы:

User (UserID, firstname, lastname, etc.)
Event (EventID, Name, Date, Location, Capacity, etc.)
EventRegistration (EventRegistrationID, UserID, EventID, ParticipantTypeID, etc.)
ParticipantType (ParticipantTypeID, Name)

ParticipantType.Name является одним из "участника" или "персонала".

Answer 2

Это кажется хорошим, хотя вы можете подумать о том, чтобы объединить ваши таблицы сопоставления пользователей и событий в одну и иметь столбец в этой таблице, который указывает цель ассоциации, то есть событие, персонал или Alt. Это эффективно устранит необходимость дублирования, которое вы описываете в таблицах UserEvent, так как Staff и Alt могут рассматриваться как надмножества Event для большинства целей.

Одним из преимуществ этого подхода является то, что он позволяет использовать несколько типов ассоциаций Пользователь - Событие, например, если у вас есть Пользователь, который является Сотрудником для События, но не Участник, или Пользователь, который просто Alt; Такой подход избавляет вас от необходимости перечислять все возможные комбинации. Теперь, если ваш дизайн явно указывает, что вы можете иметь только определенный набор типов участия пользователя, это может привести к диссоциации, которая вам не нужна; Вы можете предпочесть иметь явные ограничения на набор уровней участия, которые Пользователь может иметь на Событии. Если у вас нет этого строго определенного набора, с другой стороны, эта система позволяет легко добавлять больше ролей участия (без нарушения существующих ролей участия).

Answer 3

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