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

Question

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

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

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

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

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

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

Этот второй вопрос действительно является тем, который я хотел бы обсудить.Похоже, что много дублированного материала (все, что есть в UserStaff или UserAlt, всегда будет в UserEvent), поэтому я подумал о создании уникального ключа для таблицы UserEvent в дополнение к составному ключу, который будет использоваться в других таблицах (UserStaff и UserEvent). 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

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

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

Answer 3

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