Hallo Linuchs,
Personen, Termine und die Schnittmenge in drei DB-Tabellen.
D.h. eine M:N Beziehung (eine Person kann M Termine haben und an einem Termin können N Personen teilnehmen)? Und die "Schnittmenge" ist das, was man in relationalen Datenbanken braucht, um eine solche Relation abzubilden.
Was Du suchst, heißt "Foreign Key"
Mal angenommen, deine DB sieht so aus:
Tabelle person, primary key ist die Spalte pers_ID
pers_id INT Primary Key,
... weitere spalten
PRIMARY KEY (pers_id)
Tabelle termin
term_id INT,
... weitere Spalten
PRIMARY KEY (term_id)
Tabelle pers_term
pers_id INT,
term_id INT,
... weitere Spalten
PRIMARY KEY (pers_id, term_id)
Dann definierst Du in pers_term zwei sogenannte FOREIGN KEYS.
FK 1: von pers_id nach person.pers_id, ON UPDATE RESTRICT ON DELETE CASCADE FK 2: von term_id nach termin.term_id, ON UPDATE RESTRICT ON DELETE CASCADE
Wenn Du die Foreign Keys anlegst, solltst Du Auswahlmöglichkeiten für das ON UPDATE und ON DELETE verhalten haben.
ON UPDATE RESTRICT bedeutet: Du kannst keine ID in der Person- oder Termin-Tabelle ändern, wenn die in einer pers_term Row verwendet wird
ON DELETE CASCADE tut, wonach Du fragst: Wird eine Row in Person gelöscht, kaskadiert die Löschung über den Foreign Key, und die abhängigen Sätze in pers_term werden ebenfalls gelöscht. Das gleiche gilt, wenn Du einen Termin löschst.
Dabei könnn natürlich Personen ohne Termine oder Termine ohne Personen zurückbleiben. Dass ein Termin gelöscht wird, wenn es keine pers_term Row mehr für ihn gibt, ist mit SQL Bordmitteln nicht möglich. Ggf. sollte jeder Termin einen Besitzer haben (direkte Beziehung zu einer Person). Auch dort kannst Du einen Foreign Key definieren, so dass das Löschen einer Person alle Termine löscht, die dieser Person gehören und damit auch alle Termin_Person Beziehungen, die an dem Termin hängen.
Rolf
sumpsi - posui - obstruxi