DB-Modell für eine Software

[mkinzler]

Ich mags halt pragmatisch. Kommt aber auf den Anwendungsfall an.
Es widerspricht vielleicht der (Datenbank-)Theorie, genügt aber meinen Zwecken.

Ich würde aber Teilnahme trotzdem von einer Buchung abhängig machen und diese ggf. mit der Teilnahem mit Datum der Veranstaltung anlegen. (Vor Ort Buchung)

[AlexII]

Wie ist es mit den IDs (PK, AUTOINCREMENT) wenn ich z.B. die DB umziehe bzw. migriere, werden diese dann neu berechnet? Wenn ja dann kommen doch alle meine FK durcheinander, oder? Wie löst man das Problem?

[mkinzler]

Was meint du mit umziehen, migrieren? Vereinigen von Beständen?

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284518)

Was meint du mit umziehen, migrieren? Vereinigen von Beständen?

Wenn man z.B. von MySQL die Daten zur MariaDB überträgt. Läuft das mit meinem DB-Modell problemlos?

[mkinzler]

Sollte funktionieren, die Schlüssel sollten dafür ja nicht verändert werden.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1284522)

Sollte funktionieren, die Schlüssel sollten dafür ja nicht verändert werden.

Ok! Jetzt kann ich mit Coden loslegen.

[Dejan Vu]

Wozu dienen die beiden Felder 'zugesagt' und 'abgesagt'. Kann man beides?

[AlexII]

Zitat:

Zitat von Dejan Vu (Beitrag 1284552)

Wozu dienen die beiden Felder 'zugesagt' und 'abgesagt'. Kann man beides?

Ne, beides kann man nicht, dient nur der Übersichtlichkeit. Aber mal schauen vllt lasse ich nur eins, entweder ist die Zusage gecheckt oder nicht, geht auch.

[p80286]

Du solltest vllt. noch einmal schauen was Du bei den Personen für Daten erfasst.
a) mehr als 2 TelefonNr/Mobil-Nr. ist nicht selten.
b) Je nach Kundenkreis ist der akad. Titel enorm wichtig
c) zumindest eine vollständige Adresse wäre bei ausländischen Teilnehmern recht hilfreich
da gibt es z.B. folgende Adresse:
Herr
Willi Müller
Etage 4 Block 4
Industrieansiedlung
Industriestr 56-76
Vorort
12345 Hauptstadt

Da kommt man mit dem üblichen Name/strasse/PLZ Ort-Schema nicht so weit.

Gruß
K-H

[Dejan Vu]

Das entspricht aber nicht den Vorgaben der deutschen Post bzw. der UPU (Universal Post Union), die explizit keine inflationäre Verwendung der Adresszeilen vorschreibt. Man mag sich daran halten, oder nicht, aber *notwendig* wäre demnach nur

Code:

Name
Info1
[Info2]
PLZ Stadt
Land

Also max 5 Zeilen.
Info1: Straße, Kundennummer der Paketstation
Info2: Paketstation

In der Zeile für die Straße käme dann auch die Appartmentnummer, Seitenflügel o.ä. Und wenn das zu lang wird, wird die Zeile umgebrochen.

Welche Felder man -unabhängig davon- z.B. für die sichere Ermittlung/Abgleich der PLZ verwendet, mag jeder selbst entscheiden.

[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.