DB-Modell für eine Software

[Sir Rufo]

Ich sehe das (Speichern der Daten) eigentlich wie Dejan Vu

Wird eine Person eingeladen, dann gibt es eine Verbindung zwischen der Person und der Tagung -> die EingeladenePersonZurTagung mit den entsprechenden Merkmalen.

Sagt eine Person die Teilnahme an der Tagung zu oder ab, dann ist das einer weitere Verbindung -> TeilnehmendePersonZurTagung.

Nimmt die Person an der Tagung dann auch wirklich teil, dann entsteht eine neue Beziehung zwischen der Person und der Tagung -> die TeilgenommenePersonZurTagung.

Alle haben nicht wirklich etwas miteinander zu tun denn alle können unabhängig voneinander auftreten, aber man kann trotzdem jeden Fall hier abfragen:

Wer wurde eingeladen, hat zugesagt und nicht teilgenommen?
Wer hat teilgenommen, obwohl nicht eingeladen und abgesagt?
...

Natürlich geht das mit einer Tabelle und alles in einem Datensatz auch, aber den Kontext darf man nicht vermischen und die Abfragen werden auch umständlicher.

[jobo]

Im Kreis der Person mit Bezug zur Tagung finden sich ggF. auch Dozenten, Moderatoren, Caterer und Cheerleader oder neben den Personen entsprechende Firmen.
Man kann das immer weiter spinnen, an der Stelle ist vielleicht mal etwas Praxis fällig. Ein Datenmodell ist ja nicht in Stein gemeißelt.
Zumindest würde das für den TE bedeuten, alle die guten Vorschläge, die hier kommen, auch mal etwas einordnen zu können (Aufwand, Komplexität, ..)
Nebenbei merkt man bei der 1., 2. oder 3. Änderung noch, wie (un-)flexibel man seine Anwendung aufgebaut hat.