Thema: Eigenartige Verknüpfungen abbilden

Sagt mal, wie bildet man eigentlich Verknüpfungen ab, die sich auf eine Entität entweder der einen Entitätsmenge oder der anderen beziehen? Beispiel:

Ein Brief kann entweder an eine Privatperson oder an eine Firmenadresse geschickt worden sein. Wie verknüpfe ich nun die Serienbriefvorlage mit der jeweiligen Adresse. Klar, praktisch kann ich einfach der Verknüpfungstabelle zwei Felder geben 'privatadresse_id' und 'firmenadresse_id', wobei ich in der Applikation sicherstellen muss, dass nur eines der beiden Felder einen Wert erhält - aber ganz fein ist das ja nicht. Wie macht man sowas üblicherweise.

Und: Was, wenn eine Entitätsmenge mit einer anderen mehrfach verknüpft ist. Konkretes Beispiel: Einer Kursanmeldung werden jeweils kein oder ein Anmeldebestätigungsschreiben, Zahlungserinnerung, 1. und 2. Mahnung zugeordnet.

Bilsang hab ich vor, alle Briefe und Mails, die durch das System rausgegangen sind in einer Tabelle 'brief' zu halten, die jeweils das Datum, den Bearbeiter, je eine Verknüpfung mit der verwendeten Vorlage, dem angeschriebenen Haushalt und/oder der angeschriebenen Person, sowie den in die Vorlage tatsächlich eingesetzten Adressdaten enthalten.

In den Kursanmeldungen würde ich dann einfach ein Feld 'bestaetigungsschreiben_ID', 'zahlungserinnerung_id' usw. einrichten, die jeweils auf die Tabelle 'brief' zeigt.

Ist das der übliche Weg? Ganz sauber scheint mir das ja nicht zu sein - zumindest hab ich noch kein ERM mit derartigen Verknüpfungen gesehen.

Basti

2

Re: Eigenartige Verknüpfungen abbilden

Hi Basti,

also was dieses "Entweder Firmen-ID oder Privat-ID" angeht:
Das nennt man in der Oracle-Designumgebung einen "Arcus", der sich
so aufbaut, dass in der Tabelle "Anschreiben" 2 Spalten vorhanden sind,
jeweils die Privat-AdressenID und die Firmen-AdressenID, die auf den
Primärschlüssel der Firmen oder Privat-Adresstabelle zeigt.
Der "Arcus" kann bei Oracle (über entsprechende CHECK-Constraints) definiert werden.
Bei DB-Systemen, die sowas nicht beherrschen, muss die Prüfung dann in der Tat von der Applikation übernommen werden.
AFAIK kann MySQL derartige Constraints (noch?) nicht...

Was die Anschreiben angeht:
Sieht komplexer aus, als es am Anfang scheint.
Ich wäre jetzt zunächst von einer einfachen 1:n Beziehung ausgegangen:
- Eine Anmeldung kann 0-x Anschreiben erhalten
- Ein Anschreiben ist nur für genau eine Anmeldung gedacht

Da jetzt natürlich auch eine Erinnerungsmail an alle Anmeldungen für einen Kurs gehen kann, denke ich, liegt also eher eine n:m Beziehung vor, die über eine Zwischentabelle gelöst werden muss:
Anmeldungs-ID  ||  Korrespondenz-ID

Wobei jedes Email (ich habe das Ding jetzt mal "Korrespondenz" getauft), ebenfalls nen PK erhält und die Zuordnung dann über die obige Tabelle gelöst wird...

HTH, tink

Beleidigungen sind die Argumente derer, die keine Argumente haben

3

Re: Eigenartige Verknüpfungen abbilden

Ja, ist vielleicht geschickt so, dann ist man flexibler. Ich bin davon ausgegangen, dass die Anschreiben pro anmeldung sehr eng definiert sind: 0 oder 1 Bestätigung, 0 oder 1 Zahlungserinnerung usw. Aber damit verspielt man natürlich auch die Möglichkeit, ein Bestätigungsschreiben etc. zweimal loszuschicken.

Dank dir.
Basti