DB-Modell für eine Software

[mkinzler]

Es sind ja auch 2 Felder

select ... from ... where person = 7 and tagung = 8;

[Dejan Vu]

Das wird man aber selten brauchen. Man will eher wissen, wer alles auf einer Tagung war ('select personID from TagungsTeilnehmer where TagungsID=123') oder welche Tagungen eine Person besucht hat. Die Abfrage mit PersonID und TagungsID ist eher ein 'Hat diese Person die Tagung besucht?'

Du kannst in einer WHERE-Klausel unterbringen, was Du willst:

Code:

select * from MeineTabelle WHERE CURRENT_DATE()> '12.01.2015'

Zeigt die Tabelle nur nach dem 12.1.2015 an
und

Code:

select * from MeineTabelle WHERE 1=0

zeigt nur die Überschriften.

[AlexII]

Zitat von mkinzler:

Es sind ja auch 2 Felder

select ... from ... where person = 7 and tagung = 8;

Ich glaube ich muss anfangen ein bisschen einfacher zu denken... Ein bisschen entspannen und schon ist programmieren halb so wild.

[mkinzler]

Zitat:

Das wird man aber selten brauchen. Man will eher wissen, wer alles auf einer Tagung war ('select personID from TagungsTeilnehmer where TagungsID=123') oder welche Tagungen eine Person besucht hat. Die Abfrage mit PersonID und TagungsID ist eher ein 'Hat diese Person die Tagung besucht?'

Bzw. auf Zusatzinformationen, welche man in dieser Tabelle bezüglich der Teilnahme/Buchung ablegen könnte. Z.B. Buchungsdatum, Details zur Teilnahme usw.

[Dejan Vu]

In einer Relation? Kann man machen. Geht aber sehr schnell in Richtung => Verletzung 3NF.

[mkinzler]

Warum nicht?

SQL-Code:

CREATE TABLE TagungsTeilnehmer(
  Person Integer,
  Tagung Integer,
  BuchungsDatum DATE,
  bezahlt Integer,
  teilnehmerNr Integer,
  teilgenommen Integer,
  ...
  PRIMARY KEY( Person, Tagung),
  FOREIGN KEY( Person) REFERENCES Person ( id_person),
  FOREIGN KEY( Tagung) REFERENCES Tagung (id_tagung));

[Dejan Vu]

Kann man zusammenfassen, sollte man aber nicht (wegen der Flexibilität). Ich persönlich würde es nicht machen, da die 3NF verletzt ist. Eine Person nimmt an einer Tagung teil, die sie zuvor gebucht hat (3 Tabellen: Personen, Buchungen, Tagungen und entsprechende Relationen).

Ich kann so einer Person ermöglichen an einer Tagung teilzunehmen, ohne das sie gebucht hat. Das soll es geben. Bei deinem Ansatz müsste dann z.B. 'Buchungsdatum = NULL' sein und für die anderen Flags müsste man auch tristate logic einführen => Anti-Pattern.

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