Organização DB Schema

Question

Atualmente estou na fase de planejamento da construção de um aplicativo de programação web (para pessoal voluntário de eventos), e eu tenho uma pergunta para aqueles com mais experiência.

Fundo: Há um calendário de eventos, e qualquer usuário, a qualquer momento pode se inscrever para qualquer um dos eventos. Em um momento posterior, mas antes daquele evento, um dos administradores irá intervir e seleccionar uma "Lista pessoal" fora daqueles que registrou, eo resto será colocado em uma "lista alternativa".

O que eu tenho pensado até agora é que haverá uma tabela de eventos, uma tabela de usuário, e depois outros três:

• UserEvent
  • usuários mapas para eventos que eles registrado. não implica qualquer Estado-Maior nem a lista Alt associação.
• UserStaff
  • usuários mapas para eventos que eles registado, e também acontecerá a ser pessoal.
• UserAlt
  • Semelhante ao UserStaff

A questão torna-se então duas partes:

• Esta é uma boa maneira de fazê-lo?
• deve cada uma dessas três tabelas associativas têm a ID de usuário eo ID de evento?

Essa segunda questão é realmente o que eu gostaria de ver discutido. Isso parece uma grande quantidade de material duplicado (tudo em qualquer UserStaff ou UserAlt estará sempre em UserEvent), então eu estava pensando em criar uma chave única para a tabela de UserEvent, além da chave composta, que as outras tabelas (UserStaff e UserAlt) vai consultar. No lado positivo, há menos conteúdo duplicado, no lado de baixo há uma tabela intermediário (UserEvent) que precisa ser referenciado em quase todas as consultas desta forma.

Espero que eu tenha sido clara o suficiente, e agradece antecipadamente.

Answer 1

Eu teria as seguintes tabelas:

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

ParticipantType.Name é um dos "participante" ou "pessoal".

Answer 2

Isso parece bom, embora você pode querer considerar a combinação de seu usuário - tabelas de associação eventos em um, e ter uma coluna nessa tabela que indica a finalidade da associação, ou seja, Evento, Staff, ou Alt. Isso efetivamente evitar a necessidade de duplicação você descreve nas tabelas UserEvent, desde Pessoal e Alt poderia ser considerado como supersets de eventos para a maioria dos propósitos.

Uma vantagem dessa abordagem é que ele permite que haja vários tipos de usuário - associações de Eventos, como se você tiver um usuário que é um funcionário para um evento, mas não um participante, ou um usuário que é apenas uma Alt; esta abordagem poupa de ter que enumerar todas as combinações possíveis. Agora, se seu projeto especifica explicitamente que você só pode ter um certo conjunto de tipos de participação do usuário, isso pode introduzir um nível de dissociação você não quer; você pode preferir ter restrições explícitas sobre o conjunto de níveis de participação que um usuário pode ter em um evento. Se você não tem esse conjunto bem especificado, por outro lado, este sistema permite a adição de mais papéis de Participação facilmente (e sem perturbar papéis Participação existentes).

Answer 3

Não é uma resposta directa à sua pergunta, mas aqui está um site que eu como . Ele tem toneladas (e toneladas) de esquema de exemplo. Eu geralmente não usá-lo como definitivo (é claro), mas às vezes ele vai me dar uma idéia sobre algo que eu não estava pensando.