entwicklung	In vielen Multi-Tier-Applikationen heutzutage wird die Datenbank als reiner Datenbehälter verwendet. Auf die Frage "Wer sichert die Konsistenz der Daten zwischen diesen zwei Tabellen?" kommt meistens die Antwort "Dies wird im Applikationsserver sichergestellt!". Tabellen werden beispielsweise über objekt-relationale Mappings angebunden und die gesamte Logik außerhalb der Datenbank implementiert. Aus unserer Sicht birgt diese Vorgehensweise mindestens zwei Gefahren: Einerseits kann keine Applikation Datenkonsistenz und -integrität so gut sicherstellen wie eine Datenbank, die genau zu diesem Zweck entworfen wurde. Spätestens wenn man Daten über Loader oder Datenbank-Entwicklungstools einfügt oder ändert, wird auch der beste Applikationsserver umgangen. Andererseits bietet eine Datenbank optimierte Datenzugriffstechniken, die Datenspeicherung, Dateninhalte und -zusammenhänge berücksichtigen -- Informationen, die außerhalb der Datenbank nicht bekannt sind. Ein - optimierter - Join kann nirgends schneller laufen als in einer Datenbank. Eine Datenbank kann durchaus mehr als Extents verwalten. Angefangen bei der Datenkonsistenz, über Performance Optimierung, bis hin zur Einbettung von prozeduralen Objekten kann eine Datenbank mächtige Instrumente anbieten. Deswegen ist unser Ansatz, die Features der Datenbank - einschließlich integrierter Entwicklungsumgebungen - optimal auszunutzen. Konkret bedeutet dies unter anderem: Diejenigen Teile Programmlogik in der Datenbank zu implementieren, die dort effizienter und sicherer laufen. Normalisierte Datenstrukturen zu verwenden. Denormalisierte Tabellen sollten nur bewußt und gezielt, z.B. in den oberen Schichten eines Data Warehouse zwecks Erhöhung der Performance eingesetzt werden. Constraints sind mächtige Instrumente zur Sicherung der Datenintegrität und -konsistenz, die von der Datenbank sehr effizient überprüft werden. Daher sollten Constraints, einschließlich Relationen (Foreign Keys) benutzt werden. Alle Objekttypen der Datenbank auszunutzen - Indizes, Views, Procedures, Triggers etc. Aktives Performance Tuning zu betreiben. Kein - komplexeres - Statement sollte in Produktion gehen, bevor sein Execution Plan analysiert und für optimal befunden wurde; Statistiken sollten für alle Tabellen, Indizes und relevanten Spalten gesammelt werden etc. Parallelität immer zu nutzen, wenn sie die Datenbank anbietet und es die Ressourcen erlauben - z.B. in Selects, Create Index Statements etc. . . .