Datenbankdesign - Wie unterschiedliche Typen von Einträgen einbauen?

[drummer83]

Hallo zusammen,

ich habe folgende Frage:

Es geht um eine Datenbank (MySQL), in die Benutzer Ereignisse eintragen können und andere Nutzer können an diesen Ereignissen teilnehmen. Die Ereignisse werden in Kategorien eingeteilt (z.B. Konzert, Sport oder so). Außerdem soll angegeben werden, ob das Ereignis einmalig an einem bestimmten Datum stattfindet, regelmäßig (z.B. immer montags) oder ob es grundsätzlich ohne Datum eingetragen werden soll. Und genau da liegt mein Problem. Wie unterscheide ich diese drei Arten von Einträgen in meiner Datenbank?

Ich habe ein Diagramm der Datenbank erstellt (s. Anhang). Falls das so weit richtig ist, könnt ihr ja vielleicht einen Vorschlag zur Lösung meines Problems machen.

Wie ihr wahrscheinlich merkt, bin ich noch ganz neu auf diesem Gebiet und deshalb für jeden Tipp und jede Hilfe dankbar.

Viele Grüße und vielen Dank

drummer83

[TobiaZ]

1) festes Datum: ist kein Problem
2) regelmäßige Events: such mal nach wiederkehrende Termine o.ä. auch im Zusammenhang mit Outlook
3) Events ohne Datum: ?? schwer vorstellbar, aber lass das Datumfeld einfach leer.

[ApoY2k]

Rein modelltechnisch wären das drei verschiedene Typen von Events, die jeweils eine eigene Entity darstellen und mit der übergeordneten Entity "Event" mit einer "is-a"-Beziehung verbunden sind.

So wäre es zumindest aus reiner ERM-Sicht... wie man das dann in der DB umsetzt kommt ganz drauf an, da gibts mehrere Möglichkeiten. Die einfachste ist aber die Überrelation. Dafür haust du einfach Felder in die Event-Table rein, die dann eben heißen "fix_date", "recurrs_every".

Wenn nur "fix_date" gefüllt ist, dann ist es nur ein Datum. wenn "recurr_every" ebenfalls gewüllt ist (z.B. mit "woche", "tag", "monat" oder so), dann ist "fix_date" der erste Tag des Events und dann wird es alle "woche", "tag", etc. wiederholt.

Ein Event ohne Datum ist dann einfach gegeben, wenn keines der beiden Felder mit einem Wert belegt ist... eigentlich ganz simpel ^^

[sushimesser]

Hallo

Was hälltst du davon?
Lass die Kategorie - Ereignis Beziehung, denn so ist eine Erweiterung der Kategorien kein Problem. Du Kannst jederzeit eine neue Kategorie einführen ohne die DB durch eine neue Kategorie-Entität modifizieren zu müssen.
Vielleicht nimmst du eine neue Entität auf z.B. Veranstalltungsintervall
monatlich, täglich jährlich oder was dir sonst noch einfällt -> wäre auch jederzeit erweiterbar. Veranstalltungsintevall hätte eine m-n Beziehung zu Ereignis. Daraus resultiert die neue Tabelle z.B. Datum. Hier hättest du die Möglichkeit außer dem Datum natürlich z.B Anzahl Besucher, Ticketpreis, etc aufzunehmen. Und den User änderst du indem du eine m-n Beziehung zu Datum erstellst. Dort hättest du die Möglichkeit den User das Event bewerten zu lassen