Hi Folks !

Ich habe nochmal eine Frage zum Thema SQL und dem erweitern und Löschen von Datensätzen. Mich würde hierbei mal interessieren, ob man beim Einfügen und Löschen in Datensätzen (die mehrere Tabellen einschließen durch Fremd- und Primärschlüsselbzeihungen bzw. tabellenübergreifend sich dann auswirken müssten, um sämtliche datenbestände konsistent halten zu können). Reicht für solche Dinge ein einfach ON DELETE CASCADE bzw. ON UPDATE CASCADE bzw. On INSERT CASCADE, oder muss ich da als Entwickelr noch andere Dinge beachten, oder ist es damit schon vollendet?

Greetz
Felix

Das sollte üblicherweise reichen.

Als Entwickler sollte man aber eine gehörige Portion Respekt vor CASCADE haben und möglichst meiden. Kein Programmierer und schon gar kein User arbeitet fehlerlos. Ohne CASCADE bekommt man dann im schlimmsten Fall eine Foreign Key Violation und weiß das man da eventuell noch einen Bug fixen muß. Mit CASCADE hat man eventuell die halbe DB leergeräumt bevor man was merkt und muß sich die weinenden User anhören wenn man den was von Backup einspielen erzählt das die mit einer gewissen Wahrscheinlichkeit wieder bessseren Wissens nicht haben. CASCADE sollte man meiner Meinung nach, wenn überhaupt, nur punktuell einsetzten. Und CASCADE UPDATE ist ein Unfeature. Das braucht man eigentlich nur um Designfehler der Datenbank zu kaschieren.

Hallo,

ich sehe es auch so wie Ralf. CASCADE sollte man eigentlich nicht einsetzen, denn das Risiko für fehlerhafte Anwendung ist m.E. größer als deren Nutzen.

Danke für die bisherigen Antworten !

Ich muss nochmal nachfragen. Wie genau sollte ich den solche tabellenübergreifenden DELETES und UPDATES durchführen, wenn nicht mit CASCADE (auch unter der Berücksichtigung der Datenkonsistenz)?

Greetz
Felix

Zitat:

Wie genau sollte ich den solche tabellenübergreifenden DELETES und UPDATES durchführen, wenn nicht mit CASCADE (auch unter der Berücksichtigung der Datenkonsistenz)?

Transaktion öffnen, explizite Statements auf die einzelnen Tabellen in der richtigen Reihenfolge abfeuern, Transaktion schließen.

"explizite Statements auf die einzelnen Tabellen in der richtigen Reihenfolge abfeuern"

Ich nehme an, damit meinst Du die Update und Delete Befehle, also ich muss überall prüfen wo in der Datenbank bzw. in sämtlichen Datenbanktabellen entsprechende Datensätze vorhanden sind und dann konsequent alles rauslöschen oder entsprechend alles konsequent updaten? Ist das so korrekt?

Greetz
Felix

//Edit

Nochmal eine andere Frage:

Was genau passiert eigentlich, wenn ich manuell Änderungen in einer Datenbank vornehme? Werden diese automatisch an alle anderen betroffenen Tabellen weitergereicht und wenn nein kann man das irgendwie einstellen? Also wäre es möglich, so die explizit programmierte Transaktionssteuer, wie von Ralf jansen beschrieben, auszutricksen?

Greetz again

Zitat:

also ich muss überall prüfen

Genau darum geht es mir. Die Kontrolle behalten und nicht einfach CASCADE flächendeckend einsetzen. Natürlich kannst du irgendwann feststellen das bei einer bestimmten Relation CASCADE hilft dann ist es OK das gezielt nur an dieser Stelle einzusetzen.

Zitat:

Werden diese automatisch an alle anderen betroffenen Tabellen weitergereicht und wenn nein kann man das irgendwie einstellen?

Nenn mir mal einen sinnvolles Anwendungsbeispiel wo ein weiterreichen notwendig wäre.

Also ein konkretes Praxisbeispiel wäre vielleicht eine Artikeltabelle, wo Artikel in einer Bestellung stehen und gleichzeitig auch noch in einer Bestellpositionstabelle. Lösche ich nun die Artikel aus der Artikeltabelle, dann sollen sie auch aus den anderen beiden Tabellen verschwinden.

Lösche ich Artikel aus der Bestellungstablle, dann sollen sie auch aus allen Bestellposiitonen verschwinden.

Ich muss nochmal explizit nachfragen, weil das eben für mich so wichtig und interessant ist:

"Was genau passiert eigentlich, wenn ich manuell Änderungen in einer Datenbank vornehme? Werden diese automatisch an alle anderen betroffenen Tabellen weitergereicht und wenn nein kann man das irgendwie einstellen? Also wäre es möglich, so die explizit programmierte Transaktionssteuer, wie von Ralf jansen beschrieben, auszutricksen? "

Greetz
Felix

Hallo Felix2000

Ich hatte schon ähnliche Aufgaben zu lösen.
Ich habe in den relevanten Tabellen eine MasterID erstellt, die dann die Fremdschlüsselbeziehung unter den Tabellen "simuliert".
Auf den einzelnen Tabellen habe ich keine Fremdschlüssel definiert.
Das gibt Dir die Möglichkeit mit Delete und Insert-Befehlen genau die Datensätze zu manipulieren (ohne Berücksichtigung der Fremdschlüsselbeziehungen) die Du brauchst.
Bei diesen Transaktionen bist Du dann natürlich auch selber Verantwortlich für die korrekte Zuweisung der richtigen MasterID.
Die MasterID wird bei dieser Ausführung aus den geladenen Daten z.B. verschiedener DGV's einer Form erstellt.
Je nach Aufgabenstellung eine sehr einfache und genügende Lösung, die Daten (unabhängig) zu manipulieren.

Zitat:

"Was genau passiert eigentlich, wenn ich manuell Änderungen in einer Datenbank vornehme? Werden diese automatisch an alle anderen betroffenen Tabellen weitergereicht und wenn nein kann man das irgendwie einstellen? Also wäre es möglich, so die explizit programmierte Transaktionssteuer, wie von Ralf jansen beschrieben, auszutricksen? "

Die würden auch nur bei CASCADE weitergereicht. Normalerweise solltet es bei einer direkten Manipulaton in der Datenbank genauso ein KeyViolation geben wie in deiner Anwendung. Das würde ich auch als gut bezeichnen. Wer direkt in der DB arbeitet an einer Anwendung vorbei handelt soll schon genau wissen was er tut und gezwungen sein dann auch die entsprechenden Reihenfolgen einzuhalten(und darüber nachzudenken was er da genau macht). Es einfach zu machen führt nur dazu das zu viele Leute glauben es auch einfach mal machen zu können.

Zum 'austricksen'. Ich bin mir sicher das irgendwelche cleveren Programmierer Datenbankfrontends geschrieben haben die automatisch die Relationen in einer Datenbank ermitteln und wenn man in diesem Client dann bei einem Delete in eine KeyViolation läuft einfach diese Datensätze in der anderen Tabelle löscht (und im schlimmstenfall dann rekursiv über alle Relationen in der Datenbank).

Hi Ralf !

Besten Dank für dein Feedback! Ich muss nochmal explizit nachfragen: Was genau meinst Du mit einer "KeyViolation". Ich muss gestehen, dass mir dieser Begriff bisher unbekannt ist.

Greetz
Felix

Zu Deutsch einfach Schlüsselverletzung. Ein Datenbankspezialist nimmt da bestimmt einen anderen Begriff in den Mund aber aus der Programmiererperspektive bekommt man halt eine "KeyViolation"-Exception wenn man einen Datensatz einfügt mit einem Fremdschlüssel der in der ~fremden~ Tabelle nicht existiert, versucht einen Datensatz zu löschen dessen Primärschlüssel noch als Fremdschlüssel in einer anderen Datenbank verwendet wird oder einen Datensatz mit einem Primärschlüssel anlegt der schon existiert.

Hi Ralf !

Ich möchte ichnochmal explizit bei Dir für Deine Antworten und die damit verbundene Zeit bedanken.

Sag mal, kann man eigentlich auch Trigger (bei MSSQL Server oder Oracle oder MySQL)verwenden, um diese Aufgaben umzusetzen und wenn ja, wäre das eine saubere Lösung?

Greetz
Felix

Ralf Hallo? Könntest Du mir vielleicht ncoh meine Frage beantworten?

Ich danke Dir !!!

Ich hätte da nochmal eine Nachfrage zu dem Thema Löschung des Fremd- und Primärschlüssels aus den entsprechenden Tabellen via explizit gesetzter Transaktion. Muss ich eigentlich immer zuerst Primärschlüssel und dann die Fremdschlüssel löschen, oder umgekehrt? Wie genau ist da die korrekte Reihenfolge?

Zitat:

Wie genau ist da die korrekte Reihenfolge?

Erst Datensätze die den Fremdschlüssel enthalten dann den Datensatz wo dies der Primärschlüssel ist.

Zitat:

Sag mal, kann man eigentlich auch Trigger (bei MSSQL Server oder Oracle oder MySQL)verwenden, um diese Aufgaben umzusetzen und wenn ja, wäre das eine saubere Lösung?

Möglich ja. Mögen würde ich die aber wahrscheinlich auch eher nicht. Das ist aber eine kontroversere Meinung als beim CASCADE. Da wirst du in einem Datenbankforum auch Befürworter einer solchen Methode finden.

Hi Ralf !

Vielen Dank für deine Hilfe!

Da hat sich für mich doch noch einmal eine Frage ergeben. Gibt es eigentlich in SQL oder TSQL eine Methode, mit der sich explizit feststellen und sicher abprüfen lässt, ob eine Spalte ein Fremdschlüssel oder Primärschlüssel ist (z.B. so etwas wie isPrimaryKey() oder isForeignKey())?

Diese Methode könnte man ja quasi als zusätzliche Sicherheitsprüfung in die explizite Transaktion einbauen.

Greetz
Felix