# CASCADE Anweisungen in SQL



## kossy (2. Apr 2012)

Hallo !

Man könnte ja per CASACDE in SQL in Kombination mit der Referentiellen Integrität sicherstellen, dass wenn ein Datensatz in einer Tabelle verändert oder gelöscht wird, dies auch in allen anderen Tabellen geschieht, um so die Datenkonsistenz in der Datenbank zu bewahren.

Ich habe jetzt über diese CASADE Anweisungen gehört, dass man sie nur mit extremer Vorsicht einsetzen soll (oder am besten erst gar nicht verwenden).

Eine bessere Alternative wäre es, diese Lösch- oder Änderungsvorgänge selbst zu schreiben, umso immer zu 100% die Gewalt über seine Daten behalten zu können.

Ich verstehe jetzt aber nicht, wie genau ich bei solchen Aktionen vorgehen muss, ich meine lösche ich zuerst alle Fremdschlüssel und dann die dazugehörigen Primärschlüssel in den entsprechenden Tabellen? Oder muss ich da anders vorgehen?

Kann mir das vielleicht jemand von euch anhand eines simplen Beispieles (vielleicht über 3 oder 4 Tabellen) kurz erläutern?

Besten Dank für Antworten und Hilfestellungen !!!!

Grüße
Kossy


----------



## tfa (2. Apr 2012)

> Eine bessere Alternative wäre es, diese Lösch- oder Änderungsvorgänge selbst zu schreiben, umso immer zu 100% die Gewalt über seine Daten behalten zu können.


Die bessere Alternative wäre, dies einem ORM-Framework zu überlassen (beispielsweise Hibernate). Dort konfiguriert man nur das Mapping, die notwendigen Aktionen beim Löschen usw. gehen dann automatisch.


----------



## kossy (2. Apr 2012)

Hallo tfa !



tfa hat gesagt.:


> Die bessere Alternative wäre, dies einem ORM-Framework zu überlassen (beispielsweise Hibernate). Dort konfiguriert man nur das Mapping, die notwendigen Aktionen beim Löschen usw. gehen dann automatisch.



Danke für den Tipp mit dem OR Mapper Hibernate. Leider habe ich einen solchen in meinem aktuellen Projekt nicht zur Hand, von daher wäre es schon ganz gut, wenn mir vielleicht jemand anhand eines simplen Beispieles dieses Szenario kurz erläutern könnte.

Grüße
Kossy


----------



## nillehammer (2. Apr 2012)

Wenn Du ein gutes Datenschema hast und die Beziehungen richtig abgebildet sind, spricht nichts gegen
ON DELETE CASCADE
oder
ON DELETE RESTRICT
Für die Daten bedeutet das keine Katastrophe. Aber es wirft im Zusammenspiel mit der Anwendungsschicht ein paar Probleme auf. Stell Dir vor, Du hast zeigst ne Bestellung mit Bestellpositionen auf einer GUI an. Jemand anderes löscht die Bestellung und wegen DELETE CASCADE werden die Bestellpositionen mit gelöscht. Nun klickt der User eine Bestellposition an, die ihm zwar noch angezeigt wurde, die aber schon gelöscht ist. Über sowas musst Du Dir Gedanken machen. Dann ist DELETE CASCADE kein Problem.

... oder halt ORM-Tool ;-))


----------

