Datenbank
Performanz
3 Konsistenz


3.1 Einführung

Ein wichtiges Thema bei der Planung und Umsetzung datenbankgestützter Anwendungen im Multi-User-Umfeld ist die Konsistenz der Daten.

 

Hierbei muss sichergestellt sein, das bei einer gleichzeitigen Benutzung einer gemeinsamen Datenbasis die Daten durch die Parallelzugriffe nicht inkonsistent werden dürfen. Hierfür gibt es einige Techniken, die im praktischen Betrieb, also in der Implementierung solcher Anwendungen, immer wieder eingesetzt werden.

 

Viele dieser Techniken sind schon im Design zu berücksichtigen. Dadurch sollte man sich frühzeitig bei der Planung einer solchen Anwendung mit diesem Thema beschäftigen.

 


3.2 Nutzung von Foreign Keys

Beschreiben Sie die Beziehungen zwischen den Daten mit Fremdschlüsseln (Foreign Keys)

 

Bei der Erstellung des Datenbankmodells sollten nicht nur die Tabellen mit ihren Spalten beschrieben werden. Auch die Beziehungen der Tabellen untereinander sollten der Datenbank mitgeteilt werden.

 

Dadurch kann die Datenbank Konsistenzprüfungen auf den Daten durchführen und teilt Verletzungen dieser Konsistenz der Anwendung mit. Hierauf können Sie entsprechend reagieren. Ohne die Foreign Keys können Sie von der Anwendung heraus inkonsistente Beziehungen speichern, ohne das Sie es merken. Erst beim erneuten Lesen der Daten werden Sie bemerken, das Daten „fehlen“, ohne zu wissen, wo sich diese Daten befinden.

 

Foreign keys bedeuten für die Datenbank zwar einen erhöhten Verwaltungsaufwand beim Ändern der Daten, diese Laufzeitverluste stehen aber im keinem Verhältnis zur Konsistenz der Daten.

 


3.3 Nutzung von Transaktionen

Transaktionen sichern das konsistente Schreiben der Daten

 

Vielfach wird beim Schreiben der Daten mehr wie eine Tabelle verändert. Damit bei der Änderung der Tabellen nicht dazwischen ein Fehler auftritt und so nur Teile der Daten geschrieben und der andere Teil verworfen werden, fassen Sie die Änderungen in einer Transaktion zusammen. So wird von der Datenbank sichergestellt, das entweder alle Änderungen oder keine Änderung durchgeführt wird.

 

Heute bieten die meisten Datenbanken Transaktionskonzepte, so das diese Technik als Standard angesehen werden kann. (Vorsicht bei mySQL)

 


3.4 Versionierung von Daten

Nutzen Sie eine Versionierung der Daten bei Multi User Anwendungen

 

Bei größeren Anwendungen kommt es häufig vor, das gleiche Daten parallel von verschiedenen Benutzern gelesen und geändert werden. Damit kein Anwender Daten überschreibt, die ein anderer Anwender zuvor geändert hat, geben sie jeder Datenzeile in der Datenbank eine Version (eine eigene Spalte VERSION).

 

Beim Lesen hat jeder Anwender eine Version der Daten (welche die gleiche Version sein kann, wie sie auch ein anderer Anwender hat). Beim Schreiben der Daten beziehen Sie sich dann auf die Version und zählen diese dann um eins hoch.

 

Falls mehrere Benutzer parallel versuchen, die Daten zu schreiben, kann dies nur einer tun, da nur bei ihm die gelesene Version mit der Version beim Schreiben übereinstimmt. Der andere Anwender bekommt eine Fehlermeldung, dass seine Daten aufgrund der Version nicht geschrieben werden können. Als Entwickler der Anwendung müssen Sie dann auf solche Fehler reagieren (z.B. erneutes Laden der geänderten Daten).

 


3.5 Aufbau eines eigenen Nummerngenerators

Entwickeln Sie für die eindeutige Vergabe von Nummern einen eigenen Nummerngenerator

 

Nicht alle professionellen Datenbanken bieten ein solches Feature, weswegen Sie auch auf einen proprietären Nummerngenerator verzichten sollten.

 

Dieser Nummerngenerator lässt sich für die Vergabe der Primärschlüssel als auch für die Vergabe von Nummern in der fachlichen Implementierung einsetzen.

 


3.6 Eigener Lock von Daten

Sperren Sie Daten, deren Änderung kritisch ist

 

Um Parallelzugriffe auf Daten auszuschließen, können sie auch die entsprechenden Datensätze in der Datenbank von Hand sperren. Dadurch können Sie die Probleme, die bei der Versionierung angesprochen wurden, umgehen (dies soll aber nicht bedeuten, dass Sie auf die Versionierung verzichten sollen).

 

Hierzu benötigen Sie zwei Spalten in der Tabelle. Die eine Spalte beinhaltet den Lockzeitstempel, die andere den Lockbenutzer.

 

Falls ein Benutzer Daten zum Ändern aus der Datenbank lädt, füllt er die beiden Spalten mit Werten. Falls ein anderer Benutzer diese Daten laden will, sieht er, das ein anderer Benutzer diese Daten für sich gesperrt hat. Wenn der Benutzer die Daten geändert hat, löscht er die beiden Einträge in den Spalten und stellt so den Datensatz für andere Benutzer wieder zur Verfügung.

 

Die Zeitstempelspalte sollte in einem Timer zyklisch von der Anwendung aktualisiert werden. Falls der Client während der Bearbeitung abstürzt (soll ja vorkommen), so wird diese Spalte nicht mehr aktualisiert. So kann anhand des Zeitstempels entschieden werden, ob die Daten weiterhin gesperrt sind oder nicht.

 



Last update:  11.07.2005