SQL über Memo und edit text

[p80286]

Ein

Code:

Drop table

ist doch so subtil wie ein Vorschlaghammer, Backup darüber nageln und gut ist. So etwas wie delete from table where id mod 71=0 und das per Script alle 17 Tage, da kommt Freude auf. Die Daten sind Schrott aber es fällt nicht so schnell auf.

Gruß
K-H

[jobo]

Zitat von p80286:

delete from table where id mod 71=0

Das sind echte Gemeinheiten! Erzählst Du etwa aus Deinen alten Hackertagen?

Das wäre eine super Gelegenheit aus meiner SQL Zeit zu erzählen (vor der Erfindung von "Document Databases" , Micro Services, ..):
Wie nützlich war doch der Einsatz von Constraints! Sie verhinderten das Löschen von Datensätzen, die referentiell eingebunden sind. Dazu gehörte natürlich der Verzicht auf "Luxus" wie on-delete-cascade.(Dessen Einsatz meistens eher von Bequemlichkeit des Entwicklers zeugt)
Auch war es damals üblich, dem Normalverbraucher erst gar keine Löschrechte zu geben. Daten wurden eingegeben, korrigiert, als fehlerhaft markiert, stillgelegt, archiviert oder sonstwas, aber nicht gelöscht! Dazu braucht man dann folglich keine Löschrechte, geschweige denn "DROP" Rechte.

Ich will damit natürlich nicht sagen, dass man seitens des Client-Programms keine Schutzmaßnahmen wie etwa den Einsatz von Parametern ergreifen sollte, im Gegenteil, aber viele Schutzmaßnahmen gibt es auch für "die dumme Datenbank"! Sehr viele sogar!

[p80286]

Nö, ein Fehler der durch einen Programmfehler ausgelöst wurde (unerkannter wraparound). Und dann hab ich das ausgefeilt und einem Kollegen zum suchen gegeben.
Er war nicht amüsiert, vor allem weil das Schema nicht so leicht zu erkennen ist.

Gruß
K-H

[himitsu]

Joar, im selbstgebauten DMS hatten wir es auch, dass Dateien bei einem Kunden sporadisch verschwanden.
Hatte auch lange gedauert, bis ich den Fehler fand. Dort wurde was durch einen Trigger geändert, der RefeshAfterPost schnappte sich dadurch den falschen Datensatz und weitere Änderungen an der externen Datei gingen dann auf ein falsches Dokument los, was vor allem beim Löschen natürlich eher auffiel.

Nicht nur böse Benutzereinaben, sondern auch richtig falscher Programmcode kann viel Spaß machen.

[jobo]

Zitat von himitsu:

Nicht nur böse Benutzereinaben, sondern auch richtig falscher Programmcode kann viel Spaß machen.

Ehrlich, ich denke, das ist eine deutlich häufigere Ursache für Probleme, als missbräuchlicher Zugriff.
Man muss ja nicht paranoid reagieren, aber eine kritische Distanz zum eigenen Code (und dem irgendwelcher Libs) und die Anwendung bewährter Mechanismen kann eine Menge Schaden abwenden und auch Fehler direkt sichtbar machen.
In SQL habe ich z.B. immer schon eine gemeinsame Sequenz für die Primärschlüssel aller Tabellen verwendet. Das hat u.a. den Effekt, das fehlerhafte Updates oder Joins großteils ins Leere gehen, da nicht automatisch jede Zahl (irgend)einen Datensatz in der Tabelle trifft. Es verhindert Fehler nicht, aber findet sehr schnell Aufmerksamkeit, oft schon während der Entwicklung, spätestens in der Testphase.

[p80286]

Zitat von jobo:

In SQL habe ich z.B. immer schon eine gemeinsame Sequenz für die Primärschlüssel aller Tabellen verwendet.

Wenn die Größe des Primärschlüssels zu knapp gewählt wurde, kann das natürlich auch daneben gehen.

Gruß
K-H

[jobo]

Klar, das muss man berechnen bzw. prognostizieren.

Ich will nicht ausschließen, dass man solche Dinge bei versehentlichem Erfolg anpassen muss. Aber die wenigsten der Millionen von IT Projekten erreichen Facebook Dimensionen, wo kritische Mengen für Schlüsselgrößen erreicht würden.