DB2-Administration: Datenbankgrundlagen
Empfehlung für Programmierer
Somit lautet unsere Empfehlung wie folgt: Bevor überhaupt eine einzige Zeile Programmcode in Bezug auf die Datenbank geschrieben wird, sollten erst alle SQL-Anweisungen geschrieben und getestet werden. Beim Testen muss nicht nur auf die Richtigkeit, sondern auch schon auf die Performance geachtet werden. Hierzu stellt DB2 verschiedene ausgezeichnete Tools zur Verfügung (wie beispielsweise Explain). Wählt man diese getrennte Vorgehensweise, kann man sehr schnell und noch vor der eigentlichen Programmierung folgende Fragen klären:
Ist das Datenbank-Design aus mengenorientierter Sicht in Ordnung?
Werden alle benötigten logischen Konsistenzanforderungen wie Auslöser (Trigger) und referenzielle Integrität erfüllt?
Werden zusätzliche Datenbankobjekte wie z. B. benutzerdefinierte Funktionen (User Defined Functions - UDFs), benutzerdefinierte Datentypen (User Defined Types - UDTs) und gespeicherte Prozeduren (Stored Procedures) benötigt?
Müssen aus Performance-Gründen Änderungen am logischen oder physischen Datenbank-Design vorgenommen werden?
Können künstliche Redundanzen wie z. B. gespeicherte Abfragetabellen (Summary Tables bzw. Materialized Query Tables - MQTs) oder zusätzliche spezielle Indizes leistungssteigernd wirken?
Wir denken, die Vorteile der drei aufeinander folgenden Arbeitsschritte liegen klar auf der Hand. Denn missachtet man diese Trennung und Reihenfolge, und ist der Programmcode erst einmal geschrieben, sind die Änderungen sehr viel aufwendiger bzw. fast unmöglich.