Für mich auch ein Grund, alles solgane mit
SQL zu machen- was auch wunderbare Prüfmöglichkeiten bietet-, bis es läuft und validierte Daten liefert, dann erst ins Programm.
Ja, ganz klar, erst wenn's auf der Datenbank vollkomen korrekt funktioniert, wird's ins Programm aufgenommen.
Debuggen ist so eine Sache bei
SQL. Die Statements sind meist relativ übersichtlich. Die eigentlichen Bugs hängen ja oft in den Datensätzen (besonders bei Importen)-
Mit dem Debuggen meinte ich eigentlich auch mehr so: "Die eigenen Gedankengänge nochmal hinterfragen, steht da das, was gemeint und gewollt war." Weniger, ob es aus technischer Sicht korrekt ist.
Je komplexer
SQL wird, um so größer ist die Wahrscheinlichkeit, dass sich logische Fehler einschleichen, auch dann, wenn das, was man da gebaut hat, technisch vollkommen fehlerfrei funktioniert.
Also eher die Suche nach abstrakten, logischen Fehlern.
Technische (syntaktische) Fehler bekommt man ja beim Ausführen sofort "um die Ohren gehauen".
In PL/
SQL-Scripten größeren Umfanges kann dann die Fehlersuche schonmal etwas aufwändiger werden
