Datensatzlöschung kontrollieren

[dedlfix]

Hi!

Ist es wirklich notwendig den Erfolg der Löschung anhand der Anzahl der betroffenen Datensätze festzumachen?
zu beantworten: Ich bilde mir ein, hier mal schon gelesen zu haben, man soll nicht blind "Datensatz gespeichert" oder "Datensatz gelöscht" schreiben, wenn man gar nicht weiß, ob das auch stimmt.

Stimmt schon, man muss ja nicht unbedingt etwas hinschreiben, von dem man nur annimmt, dass es so war. Die Frage, die man sich jedoch stellen sollte ist, interessiert es in dem Fall wirklich, wieviele Datensätze gelöscht wurden oder reicht das Wissen um eine fehlerfreie Ausführung. Vielleicht hat ja parallel schon jemand gelöscht, dann ist das Ergebnis ja auch wie erwartet: Datensatz ist weg - nur war es eben jemand anderes.

Wie auch immer, die Abfrage der betroffenen Datensätze kostet nicht viel, sie in die Ausgabe der Reaktion auf die Handlung einzubauen, ist auch kein Akt. Aber wichtiger als diese Information der betroffenen Datensätze ist die Prüfung auf generelle Fehlerfreiheit der Ausführung. Dafür sollte man jedoch nicht solche "Sekundärinformation" heranziehen, sondern die bereits von den verwendeten Funktionen gelieferten Informationen auswerten. Und dann könnte die Logik so aussehen:

if query(...)
  echo (class=ok) Aktion fehlerfrei, betroffene Datensätze: affected_rows.
else
  echo (class=error) Fehlerhaft.
  administratorbenachrichtigung(error_text)

Ob der Anwender dann bei fehlerfreier Ausführung und 0 betroffenen auf die Suche geht, um nachzuschauen, ob der Datensatz trotzdem weg ist, ist seine Sache. Aber bei einem "Löschung nicht erfolgreich" wenn affected_rows als Ergebnis 0 liefert, weiß man nicht, ob es einen Fehler bei der Ausführung gab oder "nur" der Datensatz auf anderen Wegen gegangen worden ist. Man müsste dann eigentlich auf alle Fälle auf Ursachenforschung gehen, nur um dann festzustellen, dass doch schon alles in Butter ist. Beim nächsten Mal denkt man sich das auch und übergeht so einen echten Fehler.

Und zu guter Letzt könntest du auf die Idee kommen, das Prinzip der Abfrage nach den affected_rows statt dem Returnwert von query() auch auf UPDATE-Statements anzuwenden. Und da bekommst du wesentlich öfter 0 affected_rows, nämlich dann, wenn der Anwender keine Änderung gegenüber dem gespeicherten Datensatz macht (Anwender ruft einen Datensatz auf, ändert nichts, aktiviert trotzdem die Speichern-Funktionalität). query() liefert dann true, aber affected_rows ergibt 0, weil es nichts zu ändern gab. (Wobei es hierfür in MySQL eine Einstellmöglichkeit gibt, über die man entscheiden kann, ob man die wirklich geänderten oder alle von der WHERE-Klausel eingeschlossenen Datensätze gezählt haben will.)

Lo!