_hkl: OO Formulierung der Problems / SQL dazu ?

Beitrag lesen

Hallo!

Hi,

mal n schuss ins Blaue (oder in den Ofen) ;))

Tabelle C
  PK
  Payload (Nutzdaten)
  FK Referenz auf Tabelle A-PK

Tabelle A
  PK
  gemeinsame Attribute von A1 und A2

Tabelle A1
  PK = FK Referenz auf Tabelle A-PK
  A1 spezifische Payload Daten

Tabelle A2
  PK = FK Referenz auf Tabelle A-PK
  A2 spezifische Payload Daten

(Ja, du könntest in A2 und A1 jeweils denselben Key aus A referenzieren, nur warum solltest du das zweimal eintragen -> Da muss deine Geschäftslogik einsetzen und das verhindern)

Danke fuer den Vorschlag und die sehr ausführliche Antwort !

Aber verlagere ich das Problem dadurch nicht nur?
Statt zwei NOT NULL values in einer Tabelle zu verhindern, muss ich jetzt zwei gleiche FK in zwei Tabellen verhindern, oder ?

;-(

Wenn du jetzt eine Abfrage machst, kannst du direkt auf ein UNION ALL aus A1 und A2 joinen. Lediglich die Felder müssten entsprechend im Select aufbereitet werden (also SELECT A1.feldA, A1.feldB, NULL ... UNION ALL SELECT NULL, NULL, A2.feldXYZ)

Danke !

Hab auch schon über eine Domain fur die A1,A2 PK nachgedacht und die Beschraenkung auf ein - nicht als FK deklariertes Feld - in C.
Dann könnte die BL die Relation gleichsam "sythetisch" herstellen.

Mit einem CHECK Constraint wie von King Lully erwähnt geht es auch irgendwie.

OO Patterns auf RDBMS'se anzuwenden funktioniert meistens schlecht oder gar nicht.

Das ist das was ich hier interessant finde.
Hier brauch ich wirklich mal ( aus diversen Gruenden ) eine direkte Abbildung auf beide "Subsysteme".

Ohne irgendeine funktionale Klammer ( entweder Constraint Verletzung abfangen oder wie Du vorschlägst "doppelte" Inserts in der Business-Logik abfangen ) scheint's nicht zu gehen.

Ist vielleicht methodisch aufschlussreich.

Vielleicht lese ich mir auch nochmal dein initialposting durch ...

Cheers,
Frank

Nochmals vielen Dank !

Grüsse

hkl