Organización del esquema de base de datos

Question

Actualmente estoy en la fase de planificación de la creación de una aplicación web de programación (para el personal voluntario de eventos), y tengo una pregunta para aquellos con más experiencia.

Antecedentes: Hay un calendario de eventos, y cualquier usuario en cualquier momento puede registrarse para cualquiera de los eventos. En un momento posterior, pero antes de ese evento, uno de los administradores intervendrá y seleccionará una " Lista de personal " de los que se registraron, y el resto se colocará en una "Lista alternativa".

Lo que he estado pensando hasta ahora es que habrá una tabla de eventos, una tabla de usuarios y luego otras tres:

• UserEvent
  • Asigna a los usuarios a eventos en los que se registraron. No implica ni el personal ni la membresía de la lista Alt.
• UserStaff
  • Asigna a los usuarios a los eventos en los que se registraron y que también son personal.
• UserAlt
  • Similar a UserStaff

La pregunta se convierte en dos partes:

• ¿Es esta una buena manera de hacerlo?
• ¿Debería cada una de esas tres tablas asociativas tener la identificación del usuario y la identificación del evento?

Esa segunda pregunta es realmente la que me gustaría ver discutida. Parece una gran cantidad de material duplicado (todo en UserStaff o UserAlt siempre estará en UserEvent), por lo que estaba pensando en crear una clave única para la tabla UserEvent, además de la clave compuesta, que las otras tablas (UserStaff y UserAlt) se referirá a. En el lado positivo, hay menos contenido duplicado, en el lado negativo hay una tabla intermedia (UserEvent) que debe ser referenciada en casi todas las consultas de esta manera.

Espero haber sido lo suficientemente claro, y gracias de antemano.

Answer 1

Tendría las siguientes tablas:

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

ParticipantType.Name es uno de " participante " o "personal".

Answer 2

Esto parece bueno, aunque es posible que desee considerar combinar sus tablas de asociación Usuario - Evento en una sola, y tener una columna en esa tabla que indique el propósito de la asociación, es decir, Evento, Personal o Alt. Esto evitaría efectivamente la necesidad de la duplicación que usted describe en las tablas de UserEvent, ya que Staff y Alt podrían considerarse superconjuntos de eventos para la mayoría de los propósitos.

Una ventaja de este enfoque es que permite que haya múltiples tipos de asociaciones de Usuario - Evento, como si tiene un Usuario que es un miembro del personal de un evento pero no un participante, o un usuario que es solo un Alt; Este enfoque le evita tener que enumerar todas las combinaciones posibles. Ahora, si su diseño especifica explícitamente que solo puede tener un cierto conjunto de tipos de Participación del usuario, esto podría introducir un nivel de disociación que no desea; Es posible que prefiera tener restricciones explícitas en el conjunto de niveles de participación que un usuario puede tener en un evento. Si no tiene ese conjunto estrictamente especificado, por otro lado, este sistema permite agregar más roles de participación fácilmente (y sin perturbar los roles de participación existentes).

Answer 3

No es una respuesta directa a su pregunta, pero aquí hay un sitio que me gusta . Tiene toneladas (y toneladas) de esquema de muestra. Por lo general, no lo uso como definitivo (por supuesto), pero a veces me dará una idea sobre algo en lo que no estaba pensando.