Stefan: constraint

Tag zusammen,

folgende Situation:

Ich habe 2 Tabellen. Tabelle A enthält z.B. Produkte und in Tabelle B gibt es zu einzelnen Produkten aus Tabelle A noch weitere "Unterprodukte".

Jetzt möchte ich es schaffen, dass wenn man in Tabelle A ein Produkt löscht doch bitte auch gleichzeitig die abhängigen Unterprodukte aus Tabelle B gelöscht werden.

Die Tabellenstruktur:
Tabelle A: PK - ProduktID
Tabelle B: PK - UnterproduktID

In Tabelle B habe ich aber auch die ProduktID zu jedem Unterprodukt und über diesen FK kann ich doch irgendwie mittels CONSTRAINTS ... FOREIGN KEY ... REFERENCES eine Beziehung herstellen...ich weiß leider nur nicht wie :(

Kann mir jemand sagen, wie mein Create-Statement von Tabelle B aussehen muss, damit das klappt!?

Danke im Voraus!

  1. Hi,

    Ich habe 2 Tabellen. Tabelle A enthält z.B. Produkte und in Tabelle B gibt es zu einzelnen Produkten aus Tabelle A noch weitere "Unterprodukte".

    sind das nur Varianten eines Produkts ("handgeklöppelter Seidentopflappen in rot, in gelb, in grün ..."), oder sind es weitere Produkte, die zu dem Produkt gehören ("Topflappenhalter", "Topflappenputzmittel", ...)?

    Jetzt möchte ich es schaffen, dass wenn man in Tabelle A ein Produkt löscht doch bitte auch gleichzeitig die abhängigen Unterprodukte aus Tabelle B gelöscht werden.

    Bei Oracle lautet die Anweisung ON DELETE CASCADE.

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Ja - es handelt sich "nur" um Varianten des Produkts.

      Mein bisheriger Versuch:

      CREATE TABLE tableB (ID INTEGER NOT NULL, ParentProdID INTEGER, PRIMARY KEY (ID), FOREIGN KEY (ParentProdID) REFERENCES tableA (ProdID), UNIQUE (ID));

      Das klappt auch noch, aber der Insert fällt mir dann auf die Nase:
      INSERT INTO ICT865807I$0A (ID,ParentProdID) SELECT prrfnbr,prprfnbr from  ....

      Fehlermeldung:
      Der Wert von FOREIGN KEY "DB2QWCS.tableB.SQL070504141833491" zum Einfügen oder Aktualisieren entspricht keinem Wert des Primärschlüssels der übergeordneten Tabelle.  SQLSTATE=23503

      1. Hi,

        Das klappt auch noch, aber der Insert fällt mir dann auf die Nase:

        dann fehlt der entsprechende Referenzwert in der anderen Tabelle. Ändere die Reihenfolge der Inserts.

        Cheatah

        --
        X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
        X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Hi,

          Das klappt auch noch, aber der Insert fällt mir dann auf die Nase:

          dann fehlt der entsprechende Referenzwert in der anderen Tabelle. Ändere die Reihenfolge der Inserts.

          Cheatah

          Öhm, jetzt haste mich aus der Kurve geworfen.
          Was hat das mit der Reihenfolge zu tun? Meinst du damit ich muss zuerst tableB befüllen oder wie meinst du das?

          1. Hi,

            Öhm, jetzt haste mich aus der Kurve geworfen.

            deshalb: Vor dem Betreten des Forums Schutzhelm aufsetzen! ;-)

            Was hat das mit der Reihenfolge zu tun? Meinst du damit ich muss zuerst tableB befüllen oder wie meinst du das?

            Der Datensatz, den Du referenzierst, muss existieren. Es bietet sich daher an, den referenzierten Datensatz als erstes einzufügen, bevor man einen Datensatz einfügt, der ihn referenziert. Innerhalb eines auf Kausalität basierenden Universums ist somit ein Zusammenhang mit der Reihenfolge gegeben.

            Cheatah

            --
            X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
            X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
            X-Will-Answer-Email: No
            X-Please-Search-Archive-First: Absolutely Yes
            1. Morgen und einen schönen Start in die Woche!

              Um mein Problem von letzter Woche noch mal aufzugreifen:
              Tabelle A ist zum Zeitpunkt des CONSTRAINTS bereits existent und gefüllt!

              Gibts vielleicht syntaktisch noch ein Problem? Die zu grunde liegende DB ist DB2...vielleicht gibts dabei noch was zu beachten??