Datenbank
Performanz
2 Allgemeine Aspekte


2.1 Einführung

In diesem Kapitel werden Themen angesprochen, die zu einer allgemeinen Planung für eine datenbankbasierte Anwendung gehören. Diese sind unabhängig von Konsistenz oder Performanz und gelten für alle Datenbanken.

 

Viele Punkte dieses Kapitels sollten vor der eigentlichen Implementierung festgelegt werden, d.h. schon in der Planungsphase müssen diese vollständig spezifiziert sein

 


2.2 Datenklassifizierung

Unterscheiden Sie zwischen operative und statischen Daten

 

Um mit den Daten in der Datenbank umgehen zu können, muss man diese Daten genau kennen. Hierbei hat es sich als vorteilhaft herausgestellt, diese Daten mit dem Kunden zusammen zu klassifizieren.

 

Man klassifiziert zum einen operative Daten, die häufig hinzugefügt, geändert und wieder gelöscht werden. Als zweite Einordnung der Daten werden statische (read only) Daten klassifiziert. Diese Daten werden meist nur einmalig angelegt und selten bis gar nicht geändert oder gelöscht.

 

Hierzu erstellt man einfach eine Tabelle mit allen Datentabellen der Datenbank als Zeilen. Als Spalten schreibt man „operativ“ und „statisch“. So kann man anschließend die entsprechenden Felder ankreuzen.

 


2.3 Datenmengenabschätzung

Versuchen Sie, den Datentransfer einzuschätzen

 

Neben der Klassifizierung der Daten ist es auch wichtig zu wissen, wie viele Daten überhaupt im Betrieb der Anwendung anfallen. Mit einer zweiten Tabelle (oder in die erste integriert) kann man diese Abschätzung mit dem Kunden gemeinsam durchführen.

 

Man trägt wieder die Datentabellen in die Zeilen dieser Tabelle ein. Als Spalten kann man den täglichen, wöchentlichen, monatlichen und jährlichen Datentransfer pro Tabelle benutzen.

 

Hierbei sind nur grobe Schätzwerte interessant. An diesen kann man aber schon die Tendenzen bezüglich der Datenmengen erkennen.

 


2.4 Nutzung von SQL Befehlen

Benutzen Sie einfaches SQL

 

Zum Lesen und Schreiben der Daten sollte man möglichst immer SQL Befehle benutzen. Das heißt, zum Lesen benutzt man den SQL Befehl SELECT, zum Schreiben die SQL Befehle INSERT und UPDATE und zum Löschen den SQL Befehl DELETE.

 

Viele Datenbankschnittstellen bieten komfortable Recordsets (z.B. ADO, ADO,NET, DAO) an, mit denen alle Aktionen durchgeführt werden können.

 

Diese Vorgehensweise hat aber den Nachteil, dass man bei diesen Schnittstellen keinen Einblick in die Realisierung der Implementierung und damit in den eigentlichen Ablauf der Befehle hat.

 

Oft arbeiten diese Schnittstellen nicht immer so, wie man es erwartet hätte. Somit ergeben sich häufig Problematiken, die man vergleichsweise bei einer eigenen Implementierung nicht hat oder selbst beheben kann.

 


2.5 Recordsets nur zum Lesen benutzen

Vertrauen Sie auf die eigene Implementierung

 

Die Benutzung dieser Recordsets kann man bei eigener Implementierung auf Nur-Lese-Recordsets mit Nur-Vorwärts-Richtung auf serverseite beschränken. Diese Recordsets erfüllen dann alles, was man zum Lesen der Daten benötigt und sind mit diesen Einstellungen i.d.R. sehr schnell.

 

Damit sind diese Recordsets auch datenbankübergreifend einsetzbar, was eine Portierung der Anwendung auf eine andere Datenbank wesentlich vereinfacht.

 


2.6 Einsatz von Datenbankscripten

Erzeugen Sie Datenbanken nur mit Scripten, nicht mit GUI Werkzeugen

 

Wenn Datenbanken für Anwendungen aufgebaut werden müssen, dann erzeugen Sie aus dem Modell immer ein Datenbankscript. Benutzen Sie niemals die grafischen Tools zur schnellen Erzeugung der Datenbanken.

 

Die mittels grafischer Tools erstellten Datenbanken haben den Nachteil, dass man nicht immer alle Schritte zur Erzeugung der originalen Datenbank beim Aufbau einer zweiten Datenbank nachvollziehen kann (weil man einiges vergessen hat!). Somit können ungewollte Überraschungen bei der Inbetriebnahme der zweiten Datenbank vermieden werden.

 

Normalerweise hat man schon während der Entwicklung mehrere Datenbanken laufen, die man konsistent halten muss. Dies erreicht man am Besten mit Scripten.

 

Auch Update’s dieser Schemata sollten immer über ein Script erfolgen (Sie werden es spätestens dann bemerken, wenn Sie mehr als hundert Kunden betreuen sollen).

 


2.7 Aufbau von Testdatenbanken

Planen Sie genügend Testdatenbanken ein, auch beim Kunden

 

Wenn eine Anwendung entwickelt wird, stellen Sie jedem Entwickler eine eigene Datenbank als Spielwiese zur Verfügung. Jeder Mitarbeiter entwickelt eigene Teile der Anwendung, die er ausgiebig mit seinen eigenen Daten testen kann. Hierbei wird er häufig Daten einfügen und  wieder Löschen. Damit er keine Daten eines anderen Entwicklers ändert, ist der Einsatz einer eigenen Datenbank sinnvoll.

 

Zur Präsentation der Anwendung sollten Sie immer eine eigene Datenbank vorhalten. Ihr Chef oder Ihr Kunde werden sich irgendwann über den Stand der Entwicklung informieren wollen. Entwicklerdatenbanken sind hierfür selten geeignet, da hier i.d.R. alles im (Vor-) Beta Stadium ist.

 

Zum Stresstest sollten Sie eine weitere Datenbank mit vielen Daten haben. Erzeugen Sie das normale Schema und fügen Sie in die Tabellen einfach mal Millionen Datensätze ein. Mit dieser Datenbank können Sie jederzeit Performanz- und Stresstests durchführen. Hierbei fallen einige Engpässe direkt auf.

 


2.8 Aufbau eines Objektmodells

Abstrahieren Sie den Zugriff auf die Datenbank

 

Entwickeln Sie parallel zum Datenbankmodell ein Objektmodell für die Entwickler. Mit diesem Modell abstrahieren Sie den Datenbankzugriff für die Mehrzahl der Entwickler. Stellen Sie Klassen und Methoden für die Bearbeitung der Daten zur Verfügung, ohne hierbei auf die Datenbank direkt zu verweisen. (Verweis auf Mapping: Hier könnte man eventuell die Papiere von Scott Ambler nennen)

 

Zum Laden der Daten aus der Datenbank entwerfen Sie eine (oder mehrere) Factory Klassen. Zum Speichern der Daten geben Sie dem Objekt z.B. eine Save() Methode. Kein Entwickler fachlicher Logik soll sich um die Details der Datenbankanbindung kümmern müssen. Bieten Sie ihm eine vollständige Schnittstelle, um die Aufgabenbereiche einfach zu trennen.

 

Folgende Methoden können sie den Anwendungsentwicklern pro operativer Klasse zur Verfügung stellen.

 


2.9 Abstrakte Primärschlüssel

Benutzen Sie abstrakte Primärschlüssel, keine fachlichen Primärschlüssel

 

Bei der Wahl von Primärschlüssel für eine Tabelle benutzen Sie am besten abstrakte Schlüssel. Hierbei kann man eine ID Spalte mit Ganzzahlen einsetzen. Primärschlüssel aus fachlichen Daten (wie z.B. Name, Vorname) haben sich in durchgeführten Projekten als unpraktisch herausgestellt.

 

Bei Änderung der fachlichen Daten, die Teil des Primärschlüssels sind, müssen auch alle anderen Tabellen, die diese als Fremdschlüssel enthalten, geändert werden. Das ist zum einen ein enormer Verwaltungsaufwand und zum anderen performanzmindernd.

 


2.10 Einsatz von Standard-Datentypen

Seien Sie vorsichtig mit der Wahl der benutzen Datentypen. Verwenden Sie nach Möglichkeit nur Basis-Datentypen

 

Benutzen Sie nicht immer alle Datentypen, die Ihnen eine Datenbank zur Verfügung stellt. Konzentrieren Sie sich auf einige Basis-Datentypen, die Sie verwenden. Häufig finden Sie auf anderen Datenbanken keine Entsprechung solcher proprietärer Typen, so dass eine Portierung der Anwendung auf eine andere Datenbank Probleme bereitet.

 

Sollte man eventuell nur kurz den Begriff der „Datenbankunabhängigkeit“ bringen?

 


2.11 Keine Nutzung von Datenbankfeatures

Beschränken Sie sich auf einfachstes Standard SQL

 

Bei dem Entwurf der SQL Befehle (insbesondere bei Abfragen) bieten Datenbanken häufig viele Features (erweiterte Skalarfunktionen, ...). Selten sind diese Features auf anderen Datenbanken so verfügbar, so dass eine Portierung viel Mühe kostet. Verzichten Sie auf solchen „Komfort“ und programmieren Sie diese Funktionen selbst.

 


2.12 Vermeiden von Outer Join's

Weiß noch nicht, ob ich dies ansprechen soll.

 



Last update:  13.07.2005