Hallo,

das ist ja nicht verkehrt, denn gerade hier gilt, dass gutes Design durch einfache Programmierung belohnt wird und Probleme (z.B. Performance) ihre Ursachen in Huddel Design haben. Konsequente Normalisierung der Datenbank und anlegen aller daraus resultierenden Constraints und der fachlich begründeten (unique) Constraints führen dazu, dass die allermeisten Zugriffspfade damit bereits angelegt sind. Wenn man jetzt noch die Datenbankzugriffe in eine eigene Zugriffsschicht zusammen fasst, dann hat man sehr überschaubare Verhältnisse, die schnell und effektiv verifiziert werden können, meist reicht dann zur Verifikation schon ein PRTSQLINF für die Serviceprogramme der Zugriffsschicht.
Bei variablen order by Kriterien und Filtern (was mit Rekord Löffel Ekzem garnicht geht!), brauchts dann schon ein wenig mehr, aber auch hier gilt, gutes Datenbank Design hilft immens, normalisierte Tabellen haben selten mehr als 10 oder 15 sinnvolle Zugriffspfade und eine vernünftige Teststrategie (Stichwort QS) mit hinreichender Abdeckung und Produktions nahen Datenbeständen (auch vom Volumen!) sollte da Lücken in den meisten Fällen aufdecken.

mfg

Dieter Bender

Zitat Zitat von loeweadolf Beitrag anzeigen
Dann gehöre ich wohl zu der austerbenden Art von Spezies, die sich vor dem Einsatz beim Kunden Gedanken machen, um nach Möglichkeit Reklamationen zu vermeiden.
:-)