Von Access zum SQL Server – warum wechseln

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

“Access ist keine Datenbank” – so stand es im Gästebuch einer bekannten Access-FAQ. Irgendwie möchte man dem Schreiber auch Recht geben, denn Access ist mehr als eine Datenbank. Neben dem Speichern von Daten in normalisierter Form bietet Access auch die Formulare und Berichte, mit denen die Daten verwaltet beziehungsweise ausgewertet werden können. Der Schreiber wollte wohl eher kundtun, dass Access kein Datenbank-Server ist. Diese Aussage wäre absolut korrekt gewesen. Wo nun der Unterschied zwischen einer Datenbank und einem Datenbank-Server liegt und wann es sich lohnt, auf diesen zu wechseln, erfahren Sie auf den nächsten Seiten.

Access ist eine Desktop-Datenbank. Das bedeutet, dass das Datenbanksystem mitsamt der Datenbank und der Datenbank-Applikation auf dem Rechner eines Anwenders installiert ist und auch nur von einem Anwender benutzt wird. Natürlich kann Access auch im Mehrbenutzerbetrieb verwendet werden. Es gibt viele sehr gute Access-Datenbank-Applikationen im Mehrbenutzerbetrieb mit einer ausgezeichneten Performance.

Access ist nach wie vor eine leistungsfähige Entwicklungsumgebung, mit der effizient Datenbank-Applikationen entwickelt und bereitgestellt werden können. Nicht ohne Grund wird Access sowohl von Anfängern wie auch von Datenbank-Profis genutzt.

Dateiserver vs. Client/Server

Eine Access-Datenbank ist und bleibt eine Desktop-Datenbank. Egal, ob die Daten lokal von nur einem Benutzer oder im Netzwerk von vielen Benutzern aktualisiert werden: die Daten werden vom Benutzer immer direkt in der Datei geändert.

Das bedeutet, dass im Mehrbenutzerbetrieb alle Benutzer gleichzeitig mit ein und derselben Datei – mit der Access-Datenbank – arbeiten.

Access bietet also nur einen Dateiserver-Betrieb; ein Client/Server-Betrieb ist nicht möglich.

Bei einem Client/Server-Betrieb werden die Anforderungen zur Datenänderung vom Client an einen Datenbank-Server übertragen und dort vom Serverdienst umgesetzt.

Der Zugriff auf die Daten und die entsprechenden Dateien erfolgt also nur durch den Serverdienst und nicht durch jeden einzelnen Benutzer. Ein Datenbank-Server – im Sinne vom Microsoft ist das der MS SQL Server – ist für die Verwaltung großer Datenmengen und den Zugriff vieler Benutzer ausgelegt.

Genau das sind die Knackpunkte bei Access: das Datenvolumen und die Anzahl der Benutzer. Access stößt bei großen Datenmengen und vielen Benutzern schnell an seine Grenzen. Am schnellsten merkt man das bei der Performance.

Performance

Den Anwender interessiert nur die Geschwindigkeit. Gerade bei einer Datenbank-Applikation will der Benutzer nicht auf die Informationen warten. Merkmale wie Skalierbarkeit, Datensicherheit und so weiter interessieren ihn nicht. Schnell muss es gehen.

Aber gerade die Performance leidet als Erstes, je mehr Daten beziehungsweise je mehr Benutzer einer Access-Datenbank zugemutet werden. Dies ist auf die Architektur von Access zurückzuführen, da mit einer Desktop-Datenbank im Mehrbenutzerbetrieb im Prinzip nur eine Dateiserver-Lösung erzielt werden kann.

Für die Bereitstellung einer Access-Datenbank im Mehrbenutzerbetrieb gibt es mehrere Möglichkeiten. Eine Variante ist die Freigabe der Access-Datenbank über ein Netzlaufwerk. Jeder Benutzer arbeitet mit der freigegebenen Access-Datenbank, das heißt mit der freigegebenen Datei.

Eine andere Variante ist das Trennen von Daten und Programmlogik. Dazu werden die Daten – die Tabellen – in einer eigenen Access-Datenbank gespeichert und diese Datenbank wird mit einer weiteren Access-Datenbank – der eigentlichen Applikation mit Formularen, Berichten, Abfragen und Modulen – verknüpft. Die Datendatei wird auf einem Netzlaufwerk und die Programmdatei auf den jeweiligen Clients der Benutzer installiert.

Egal welche Installationsmethode verwendet wird: die Daten werden immer auf dem Client des Benutzers verarbeitet. Bei der ersten beschriebenen Variante wird dafür die komplette Access-Datenbank auf den Client kopiert.

Bei der zweiten beschriebenen Variante werden die Tabellen mit den für die Verarbeitung notwendigen Daten an die auf dem Client installierte Access-Datenbank übermittelt und dort von der Jet-Engine verarbeitet.

Die Daten werden also bei beiden Varianten über das Netzwerk an den Client übertragen. Und je mehr Daten in einer Datenbank gespeichert werden, desto mehr Daten werden übertragen.

Zur Verdeutlichung ein kleines Beispiel: Eine bestehende Datenbank ist in Daten und Programmlogik aufgeteilt. Die Datenbank mit den Daten liegt auf einem Netzlaufwerk. Diese Datenbank enthält eine Tabelle mit Rechnungen, in der auch der Zahlungseingang vermerkt ist. Die Tabelle umfasst 500.000 Datensätze. Auf den Clients ist die Access-Datenbank mit der Programmlogik installiert. Diese enthält einen Bericht, der alle Rechnungen ohne Zahlungseingang auflistet.

Die Daten für den Bericht werden von der Jet-Engine der Access-Datenbank mit der Programmlogik – also die auf dem Client installierte Access-Datenbank – gefiltert. Dazu müssen normalerweise alle 500.000 Datensätze an den Client übertragen werden.

Im Client/Server-Betrieb wird lediglich die dem Bericht zu Grunde liegende Abfrage an den Datenbank-Server übergeben; dieser verarbeitet die Abfrage und liefert die Ergebnismenge an den Client zurück. Bei dieser Methode wird nicht nur das Netzwerk weniger belastet, sondern auch die Rechenleistung eines Servers und nicht die des Clients genutzt.

Während es im Dateiserver-Betrieb also auf die Performance des Netzwerks und der Hardware des Clients ankommt, ist im Client/Server-Betrieb in erster Linie die Hardwareausstattung des Servers wichtig. Die Hauptaktivität im Client/Server-Betrieb liegt beim Server, insofern sind die Hardware-Anforderungen an die Clients hier nicht so hoch wie im Dateiserver-Betrieb.

Natürlich kann mit entsprechender Netzwerkbandbreite und Hardwareausstattung der Clients an der Performance-Schraube gedreht werden und es gibt durchaus Access-Applikationen, die trotz vieler Benutzer und großer Datenmengen immer noch sehr schnell sind.

Aber auch diese Applikationen können an ihre Grenzen stoßen; denn Access kann nicht unbegrenzt skaliert werden.

Skalierbarkeit

Am Anfang stand eine kleine Informationslücke. Diese wurde mit einer Access-Datenbank gestopft. Mit dem Informationsbedarf stieg auch der Informationsgehalt – und damit auch die Größe der Datenbank. Und da die Daten nicht nur für einige, sondern für immer mehr Benutzer wichtig wurden, stieg auch die Anzahl der Datenbankbenutzer.

So ungefähr könnte die Geschichte einer Access-Datenbank aussehen, die an ihre Grenzen gestoßen ist. Diese Grenzen sind schnell genannt: Access kann maximal 2 GB Daten speichern und nicht mehr als 255 Benutzer verwalten. Nun gut – die Obergrenze für eine noch einigermaßen performante Access-Datenbank dürfte bei 20 Benutzern liegen. Es sollen aber auch Access-Datenbanken mit weitaus mehr Benutzern im Einsatz sein.

Beim SQL Server sehen die Zahlen etwas anders aus: SQL Server kann als Workgroup Edition bzw. als Enterprise Edition bis zu 1.048.516 TB Daten pro Datenbank speichern und 32.767 Benutzerverbindungen verwalten. Die kostenlose Variante – die SQL Server 2005 Express Edition – kann genauso viele Benutzerverbindungen verwalten, aber maximal 5 GB Daten speichern.

Die Zahlen sprechen für sich. Gerade die Anzahl der Benutzer macht den Unterschied zwischen Theorie und Praxis deutlich. Bei Access sind zwar maximal 255 Benutzer möglich, aber je mehr Benutzer an einer Access-Datenbank arbeiten, desto instabiler wird diese Datenbank.

Mit jedem Benutzer wird der Abgleich der Daten für die Jet-Engine schwieriger, was das Risiko des Datenverlustes oder einer Dateninkonsistenz erhöht.

Womit ein weiterer Aspekt für einen Umstieg auf SQL Server genannt wäre: Stabilität und Sicherheit.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar