MySQL - gibt es Löschschutz ?

[Kalle_Worms]

Hallöle,

ich kenne das aus einem ORACLE- Projekt:

Datensätze dürfen nur nach bestimmten Prüfungen gelöscht werden, zum Beispiel muss beim Löschen eines Kunden gewährleistet sein, dass er keine (offene) Rechnung mehr hat.

Kann man solche Regeln in MySQL hinterlegen?

Wenn ja, wo kann man sich einlesen?

Gruß, Kalle

[Ludger]

Hi,

Datensätze dürfen nur nach bestimmten Prüfungen gelöscht werden, zum Beispiel muss beim Löschen eines Kunden gewährleistet sein, dass er keine (offene) Rechnung mehr hat.

das sind doch sog. Fremdschluessel, deren Einhaltung MySQL erzwingt. Referenzielle Integritaet koennte ein Suchwort sein.

Gruss,
Ludger

[Sven Rautenberg]

Moin!

Datensätze dürfen nur nach bestimmten Prüfungen gelöscht werden, zum Beispiel muss beim Löschen eines Kunden gewährleistet sein, dass er keine (offene) Rechnung mehr hat.

Kann man solche Regeln in MySQL hinterlegen?

Hängt etwas davon ab, welches MySQL du meinst. Ich tendiere allgemein aber zu "nein".

Das, was du vermutlich suchst, sind "stored procedures". Die können komplexere Vorgänge innerhalb der Datenbank erledigen - unter anderem sicherlich auch eine Prüfung, ob ein Kunde noch offene Rechnungen hat.

MySQL in Version 3.x kennt sowas definitiv nicht. Ob MySQL 4.0 sowas schon kennt - schau in die Doku. MySQL 4.1 ist, was die Features angeht, nochmal eine Stufe weiter, aber angeblich noch immer "beta". Und dass schon über MySQL 5.0 geschrieben wird, ist zwar schön und gut, aber das dürfte allenfalls Alpha-Status sein.

Außerdem brauchst du eventuell eine Lizenz, wenn du MySQL 4.x einsetzt - hängt von deiner Software und dem Einsatzumfeld ab. Lies die Lizenzbedingungen von MySQL dazu.

Mir fallen nur zwei Alternativen ein:
1. Andere Datenbank. POSTGRESQL ist eine sehr schöne Datenbank, die alles bietet, was man vernünftigerweise von einer Datenbank erwarten kann, inklusive Stored Procedures. Das Feature-Angebot geht jedenfalls weit über das hinaus, was man von MySQL 3.x gewohnt ist. Die Datenbank ist tendentiell etwas langsamer, aber das dürfte schlicht daran liegen, dass die Features (die man ja nicht alle benutzen muß) einfach Zeit kosten.

2. Du kannst natürlich auch komplett verhindern, dass in deiner MySQL-Datenbank überhaupt Datensätze gelöscht werden, indem du dem DB-Benutzeraccount kein Recht gibst, DELETE oder DROP auszuführen. Stattdessen gibt es beim Kunden ein Feld, in dem der Status "gelöscht ja/nein" verzeichnet ist, und das beim Löschen dann einfach auf ja gesetzt wird. Ist zwar nicht so elegant, hat aber den auch nicht zu verachtenden Vorteil, dass der Kunde nicht komplett aus den Aufzeichnungen verschwindet - schließlich hat man ja doch eine gewisse Dokumentationspflicht gegenüber z.B. dem Finanzamt.

- Sven Rautenberg

[Kalle_Worms]

Moin, Sven,

erstmal danke für deine ausführliche Stellungnahme.

Das, was du vermutlich suchst, sind "stored procedures".

Ist was Schönes, aber das meine ich NICHT. Die verhindern ja nicht das direkt eingegebene SQL- Kommando "DELETE ..."

Ich habe den ORACLE- Begriff nicht mehr im Kopf. Es war wohl so was wie "restrictions". Und die wurden bei jedem SQL- Kommando erstmal durchgeprüft. Ja, es konnte auch wohl ein Verweis auf eine Stored Procedure sein.

MySQL in Version 3.x kennt sowas definitiv nicht.

Okay, dann muss ich nicht weiter suchen.

Mir fallen nur zwei Alternativen ein:

1. Andere Datenbank. POSTGRESQL ist eine sehr schöne Datenbank

dann müsste ich wohl den Provider wechseln.

2. Du kannst natürlich auch komplett verhindern, dass in deiner MySQL-Datenbank überhaupt Datensätze gelöscht werden

Ja, so mache ich es zur Zeit mit Loesch- Kennzeichen. Aber es gibt Saetze, die können nach entspr. Prüfung wirklich raus. Zum Beispiel Artikel aus einem Katalog.

Kalle.

[Ludger]

Hi,

Das, was du vermutlich suchst, sind "stored procedures".
Ist was Schönes, aber das meine ich NICHT. Die verhindern ja nicht das direkt eingegebene SQL- Kommando "DELETE ..."

och, wenn Du nie direkt Daten loescht mit "DELETE", sondern mit "SP_DELETE", dann koennte durchaus die Loeschung einzelner Datensaetze an bestimmte Bedingungen gebunden sein. Und mithilfe des Rechtesystems und einigem Finetuning koenntest Du den jeweiligen Datenbanknurtzer eben nur bestimmte SPs ausfuehren lassen, die den direkten Datenzugriff (CRUDL) eingepackt haben.

Ich habe den ORACLE- Begriff nicht mehr im Kopf. Es war wohl so was wie "restrictions". Und die wurden bei jedem SQL- Kommando erstmal durchgeprüft. Ja, es konnte auch wohl ein Verweis auf eine Stored Procedure sein.

Trigger! Die sind fuer viele Einstellungen auf Datensatzebene geeignet.

Ja, so mache ich es zur Zeit mit Loesch- Kennzeichen. Aber es gibt Saetze, die können nach entspr. Prüfung wirklich raus. Zum Beispiel Artikel aus einem Katalog.

Loeschkennzeichen werden aber nicht vom RDBMS verwaltet. Noch nicht.   ;-)
Darum willst Du von denen weg, stimmts?

Gruss,
Ludger

[Sven Rautenberg]

Moin!

och, wenn Du nie direkt Daten loescht mit "DELETE", sondern mit "SP_DELETE", dann koennte durchaus die Loeschung einzelner Datensaetze an bestimmte Bedingungen gebunden sein.

MySQL 3.x kennt keine stored procedures.

Trigger! Die sind fuer viele Einstellungen auf Datensatzebene geeignet.

MySQL 3.x kennt keine Trigger.

- Sven Rautenberg

[Ludger]

Hi,

och, wenn Du nie direkt Daten loescht mit "DELETE", sondern mit "SP_DELETE", dann koennte durchaus die Loeschung einzelner Datensaetze an bestimmte Bedingungen gebunden sein.

MySQL 3.x kennt keine stored procedures.

Du bist ja mit den SPs gekommen und ich habe erlaeutert, warum diese fuer den ins Auge gefassten Zweck taugen wuerden, was der Anfragende ja bezweifelt hat.

Trigger! Die sind fuer viele Einstellungen auf Datensatzebene geeignet.

MySQL 3.x kennt keine Trigger.

Der Anfragende hat auf ORACLE-Objekte Bezug genommen, deren Namen ihm nicht mehr gewahr waren, darum mein freundlicher Hinweis.

Die Grenzen von MySQL und Co. sind mir schon ansatzweise bekannt.   ;-)

Gruss,
Ludger

[Andreas Lindig]

Hallo,

scheint mir bei Dir schon um Fremdschlüssel zu gehen: "referenzielle Integrität" ist das Stichwort. Aber das kennt MySQL nicht. Dafür muß man halt die Applikation entsprechend sorgfältig schreiben, so daß sie diese Prüfungen immer übernimmt. Dann geht das auch. Wer unbedingt die Sicherung in der DB braucht hat ein löchriges Konzept.

Gruß, Andreas

[Ilja]

yo,

Das, was du vermutlich suchst, sind "stored procedures".

in aller regel sind das erst einmal fremdschlüssel. diese erfüllen genau einen zweck, nämlich die datenintegrität aufrecht zu halten und nicht wie oftmals vermutet, die tabellen miteinander zu verbinden.

Ilja

[Sven Rautenberg]

Moin!

in aller regel sind das erst einmal fremdschlüssel. diese erfüllen genau einen zweck, nämlich die datenintegrität aufrecht zu halten und nicht wie oftmals vermutet, die tabellen miteinander zu verbinden.

Wenn ich einen Kunden erst dann löschen darf, wenn die Summe aller seiner Bestellungen und geleisteten Zahlungen Null ergibt, dann kann man das schwerlich per Fremdschlüssel abbilden. Das würde dann nämlich erfordern, dass die dem Kunden zugeordneten Buchungen gelöscht werden müssen, bevor der Kunde gelöscht werden kann. Aber Buchungen löscht man nicht, die müssen erhalten bleiben.

Ob man nun Kunden löscht, darüber kann man sich sicherlich streiten. Ich würde es nicht tun. :)

- Sven Rautenberg

[Ilja]

yo,

Wenn ich einen Kunden erst dann löschen darf, wenn die Summe aller seiner Bestellungen und geleisteten Zahlungen Null ergibt, dann kann man das schwerlich per Fremdschlüssel abbilden.

das kommt auf sein datenbank-design drauf an. wenn alle offenen rechnungen sich in einer tabelle befinden und beglichene in eine anderen tabelle, bzw. ins archiv wandern dann schon. das auslagern in eine seperate tabelle bei offenen rechnungen bietet sich nämlich bei grossen datenmengen an. ansonsten müsste man vermutlich wirklich auf trigger ausweichen.

Ilja

[Ludger]

Hi,

Wenn ich einen Kunden erst dann löschen darf, wenn die Summe aller seiner Bestellungen und geleisteten Zahlungen Null ergibt, dann kann man das schwerlich per Fremdschlüssel abbilden.

das kommt auf sein datenbank-design drauf an. wenn alle offenen rechnungen sich in einer tabelle befinden und beglichene in eine anderen tabelle, bzw. ins archiv wandern dann schon.

Rechnungen in zwei Relationen? Waere das nicht eine _TODSUENDE_ i.p. Datendesign? Und das nutzt Du als "Rueckzugsargumentation" oder "Beharrungsargumentation"?   ;-)

das auslagern in eine seperate tabelle bei offenen rechnungen bietet sich nämlich bei grossen datenmengen an.

Ab wievielen Datensaetzen bietet sich das an? BTW - Dateigruppenbildung (also die Relation auf mehrere dateien verteilen) waere doch zu erwarten, oder?   ;-)

(BTW - ich hatte das Ausgangsposting dieses Threads im ersten Moment auch missverstanden.)

Gruss,
Ludger

[Ilja]

yo,

Rechnungen in zwei Relationen? Waere das nicht eine _TODSUENDE_ i.p. Datendesign? Und das nutzt Du als "Rueckzugsargumentation" oder "Beharrungsargumentation"?   ;-)

nun, laut normalisierung ist es streng genommen eine entität. aber wird sind nicht nur theoretiker, sondenr es soll sich ja eher in der praxis bewähren. im laufe der zeit können bei einer firma schon sehr viele rechnungen aufkommen. und deshalb macht diese inhaltliche trenung schon sinn und ist auch sicherlich keine todsünde.

Ab wievielen Datensaetzen bietet sich das an? BTW - Dateigruppenbildung (also die Relation auf mehrere dateien verteilen) waere doch zu erwarten, oder?   ;-)

ich denke mal, hier kann man keine pauschale aussage machen, sondern probieren geht über studieren. man muss halt abwägen, mehr verwaltungsaufwand vs mehr performance. eine tabelle auf mehrere dateien zu verteilen, hat nichts unbedinkt mit der inhaltlichen trennung zu tun. dass kann man auch so machen. besonders gerne wird zum beispiel ein index auf eine andere festplatte gelegt.

Ilja

[Andreas Korthaus]

Hi Sven!

MySQL 4.1 ist, was die Features angeht, nochmal eine Stufe weiter, aber angeblich noch immer "beta".

Also MySQL 4.1 kann AFAIK noch keine Stored Procedures (siehe http://dev.mysql.com/doc/mysql/en/Stored_Procedures.html), erst MySQL 5.0: http://dev.mysql.com/doc/mysql/en/TODO_MySQL_5.0.html.

Viele Grüße
Andreas

PS: MySQL 4.1 ist inzwischen "stable" - oder was hast Du gemeint?