DB Schema Organisation

Question

Ich bin gerade dabei, eine Web-Planungs-App zu erstellen (für die freiwillige Besetzung von Veranstaltungen), und ich habe eine Frage für diejenigen mit mehr Erfahrung.

Hintergrund: Es gibt einen Kalender mit Ereignissen, und jeder Benutzer kann sich jederzeit für eines der Ereignisse registrieren. Zu einem späteren Zeitpunkt, aber vor diesem Ereignis, tritt einer der Admins ein und wählt eine "Mitarbeiterliste" aus denen, die sich registriert haben, und der Rest wird in eine "Alternative Liste" aufgenommen.

Was ich bisher gedacht ist, dass es eine Ereignistabelle, eine Benutzertabelle, und dann drei andere:

• Userevent
  • Maps-Nutzer auf Ereignisse sie registriert. Impliziert weder die Mitarbeiterliste noch die Alt-Mitgliedschaft.
• UserStaff
  • Maps-Nutzer auf Ereignisse registriert sie, und auch Personal geschehen sein.
• UserAlt
  • Ähnlich UserStaff

Die Frage ist dann zwei Teil:

• Ist dies ein guter Weg, es zu tun?
• Sollte jede dieser drei assoziativen Tabellen die Benutzer-ID und die Ereignis-ID haben?

Diese zweite Frage ist wirklich die, die ich gerne diskutiert sehen würde. Das scheint viel doppeltes Material zu sein (alles in UserStaff oder UserAlt wird immer in UserEvent sein), also dachte ich darüber nach, einen eindeutigen Schlüssel für die UserEvent-Tabelle zu erstellen, zusätzlich zu dem zusammengesetzten Schlüssel, den die anderen Tabellen (UserStaff und UserAlt) verweist auf. Auf der positiven Seite gibt es weniger duplizierten Inhalt, auf der anderen Seite gibt es eine Zwischen-Tabelle (UserEvent), die in fast jeder Abfrage auf diese Weise referenziert werden muss.

Hoffentlich war ich klar genug, und danke im Voraus.

Answer 1

würde ich die folgenden Tabellen:

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

ParticipantType.Name ist einer der "Teilnehmer" oder "Personal".

Answer 2

Dies scheint gut zu sein, obwohl Sie möglicherweise in Erwägung ziehen, Ihre Benutzer - Ereignisverknüpfungstabellen zu einer zu kombinieren und eine Spalte in dieser Tabelle zu haben, die den Zweck der Verknüpfung angibt, z. B. Ereignis, Staff oder Alt. Dies würde die Notwendigkeit für die Duplizierung, die Sie in den UserEvent-Tabellen beschreiben, effektiv umgehen, da Staff und Alt für die meisten Zwecke als Obermengen von Event betrachtet werden könnten.

Ein Vorteil dieses Ansatzes besteht darin, dass mehrere Arten von Benutzer - Ereignis - Verknüpfungen möglich sind, z. B. wenn Sie einen Benutzer für ein Ereignis, aber keinen Teilnehmer oder einen Benutzer haben, der gerade ist ein Alt; Dieser Ansatz erspart Ihnen die Aufzählung aller möglichen Kombinationen. Wenn Ihr Design explizit angibt, dass Sie nur bestimmte Benutzerbeteiligungstypen haben können, führt dies möglicherweise zu einer Dissoziationsstufe, die Sie nicht möchten. Es kann sein, dass Sie explizite Einschränkungen für die Anzahl der Teilnahmeebenen haben, die ein Benutzer für ein Ereignis haben kann.Wenn Sie diese eng spezifizierte Menge nicht haben, ermöglicht dieses System andererseits das Hinzufügen weiterer Partizipationsrollen (und ohne bestehende Partizipationsrollen zu stören).

Answer 3

Keine direkte Antwort auf Ihre Frage, aber here's a site I like. Es hat Tonnen (und Tonnen) Beispielschema. Ich benutze es im Allgemeinen nicht als definitiv (natürlich), aber manchmal gibt es mir eine Idee zu etwas, an das ich nicht gedacht habe.