Frage zum besten Vorgehen: LIMIT bei UPDATE und/oder DELETE (z. B. bei MariaDB/MySQL) zur Verhinderung von "Disastern"

  • SQL

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    Frage zum besten Vorgehen: LIMIT bei UPDATE und/oder DELETE (z. B. bei MariaDB/MySQL) zur Verhinderung von "Disastern"

    Es gibt in SQL, theoretisch unabhängig vom verwendeten System (in meinem Fall ist es MariaDB bzw. MySQL), den Befehl LIMIT. Grundsätzlich ist mir die Benutzung klar, setze ihn aber im Regelfall nur bei SELECT-Statements ein.

    Nun habe ich mich gefragt, ob es sinnvoll ist, aus reinen Sicherheitsgründen bei UPDATE und DELETE ein LIMIT 1 zu machen, um zu verhindern, dass, aus welchem Grund auch immer (hauptsächlich Programmierfehler), mehr als der eine beabsichtigte Datensatz gelöscht oder aktualisiert wird.

    Beispiele:

    SQL-Abfrage

    1. UPDATE user SET name = "Marcus" WHERE id = 1 LIMIT 1;

    und

    SQL-Abfrage

    1. DELETE FROM user WHERE id = 1 LIMIT 1;

    In dem Fall ist id natürlich der Primärschlüssel und kann nur ein Mal vorkommen. Aber evtl. ändert sich irgendwann mal irgendwas an der Tabelle oder der SQL-Anweisung und aus irgendeinem Grund (kann eigentlich nur ein Programmier- oder Konzeptionsfehler sein) sind plötzlich mehrere Datensätze betroffen, was fatal wäre.

    Wie macht ihr das? Zur Sicherheit ein LIMIT dran (tut keinem weh) oder ist das schlechter Programmierstil? Im Prinzip ist es generell nur eine Stilfrage, die ich hier stelle.

    Ich konnte im Internet zu genau dieser Problematik nur exakt ein Topic finden (dba.stackexchange.com/question…only-return-one-row-anywa), was mir aber zu wenig kommentiert wurde.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Ich hänge mich da mal an, solch eine Idee hatte ich neulich auch. Beim SQL Server wäre das wohl TOP statt LIMIT, aber gleiches Prinzip vermutlich.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Guter Ansatz - es kann aber m.M.n. auch dort zu Fehlinterpretationen kommen.

    Wenn die Annahme ist, dass WHERE b = <value>; die Treffermenge filtert (Im Beispiel auf genau einen Datensatz) und man das mit LIMIT 1 festsetzen will - ist nie sichergestellt, dass bei fälschlicher Rückgabe von bspw. 2 Datensätzen der richtige gelöscht wird. Es könnte Probleme verhindern, einen aber auch in falscher Sicherheit wiegen.

    Edit 1:
    Möglich wäre - je nach Architektur mit Transactions und Rollback zu arbeiten - ein Command ausführen, nachträglich schauen wie viele Zeilen betroffen waren - und wenn das nicht passt Rollback. Setzt aber immer voraus dass man weiß was man tut / tun will.

    Edit 2: Ebenso könnte die Annahme, etwas mit LIMIT X zu limitieren, mitunter im Laufe eines Projektes veralten und obsolet werden. Das kann dazu führen, dass zu wenig verarbeitet wird oder die Daten inkonsistent werden.


    VG,
    Acr0most
    Wenn das Leben wirklich nur aus Nullen und Einsen besteht, dann laufen sicherlich genügen Nullen frei herum. :D
    Signature-Move 8o
    kein Problem mit privaten Konversationen zu Thema XY :thumbup:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Acr0most“ ()

    mrMo schrieb:

    Beim SQL Server wäre das wohl TOP statt LIMIT, aber gleiches Prinzip vermutlich.

    Ja, ist es. Laut w3schools.com/sql/sql_top.asp gibt es LIMIT, TOP und FETCH FIRST, die alle dasselbe machen (also je nach DBMS).

    Acr0most schrieb:

    ist nie sichergestellt, dass bei fälschlicher Rückgabe von bspw. 2 Datensätzen der richtige gelöscht wird.

    Das ist wohl richtig, aber besser einen falschen als alle löschen oder updaten, so zumindest mein Gedanke.

    Acr0most schrieb:

    mit Transactions und Rollback zu arbeiten

    Möglich, aber ziemlich umständlich.

    Acr0most schrieb:

    mitunter im Laufe eines Projektes veralten und obsolet werden

    Kann passieren. Somit sollte man wohl lieber ein LIMIT nur da machen, wo es Sinn ergibt. Z. B. "lösche die 10 ältesten Einträge".
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Ich denke, das Thema, ein LIMIT/TOP etc. als Sicherheit zu verwenden, ist zu konstruiert. Entweder, ein Statement ist korrekt und ändert/löscht die entsprechende Ergebnismenge oder es ist fehlerhaft und muss entsprechend korrigiert werden. Ein Limit schützt mitnichten davor, dass falsche Daten manipuliert werden, wenn das Problem z.B. eigentlich eine falsche ORDER BY-Klausel ist. Änderungen an Statements müssen halt gründlich getestet werden und ein gutes Sicherungskonzept der Datenbank schützt vor korrupten Daten.

    Danke für euren Input. Ich habe mich nun gegen ein LIMIT in Fällen entschieden, wo es nicht zwingend erforderlich ist. Ich denke, es ist wirklich eine falsche Sicherheit, in der man sich da wiegt.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Würde aber nicht verhindern, dass die nachfolgende DELETE- oder UPDATE-Anweisung fehlerhaft ist. Der Ursprungsgedanke war, dass der tatsächliche Lösch- oder Aktualisierungsbefehl fehlerhaft sein kann.
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum