<\/p>\n
„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.<\/b><\/p>\n<\/p><\/div>\n 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. <\/p>\n 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. <\/p>\n 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.<\/p>\n Das bedeutet, dass im Mehrbenutzerbetrieb alle Benutzer gleichzeitig mit ein und derselben Datei – mit der Access-Datenbank – arbeiten.<\/p>\n Access bietet also nur einen Dateiserver-Betrieb; ein Client\/Server-Betrieb ist nicht möglich. <\/p>\n Bei einem Client\/Server-Betrieb werden die Anforderungen zur Datenänderung vom Client an einen Datenbank-Server übertragen und dort vom Serverdienst umgesetzt.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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. <\/p>\n 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. <\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Aber auch diese Applikationen können an ihre Grenzen stoßen; denn Access kann nicht unbegrenzt skaliert werden.<\/p>\n <\/p>\n 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. <\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n Mit jedem Benutzer wird der Abgleich der Daten für die Jet-Engine schwieriger, was das Risiko des Datenverlustes oder einer Dateninkonsistenz erhöht.<\/p>\n Womit ein weiterer Aspekt für einen Umstieg auf SQL Server genannt wäre: Stabilität und Sicherheit.<\/p>\n „Viele Köche verderben den Brei.“ Der Vergleich hinkt zwar etwas, aber bei Access könnte man durchaus sagen: Viele Benutzer verderben die Datenbank.<\/p>\n Neben dem bereits erwähnten Problem, das die Jet-Engine mit mehreren Benutzern hat, kommt noch ein weiteres Problem hinzu: Die Daten einer Access-Datenbank im Mehrbenutzerbetrieb werden immer über das Netzwerk geändert. Falls es nun beim Schreiben der Daten über das Netzwerk zu einem Fehler kommt, kann die Datenbankkonsistenz darunter durchaus leiden, was eine Datenbankreparatur zur Folge hat, für die Access das Tool „Reparieren und Komprimieren“ anbietet.<\/p>\n Natürlich ist durch den Einsatz eines SQL Servers ein Netzwerkfehler nicht ausgeschlossen. Doch die Auswirkungen auf die Datenbank halten sich in Grenzen. Im Gegensatz zu Access wird beim SQL Server jede Aktion an der Datenbank protokolliert. Sollte es zu einem Netzwerkfehler oder einer anderen Störung kommen, wird die Datenbank anhand dieses Protokolls wieder in den letzten konsistenten Zustand versetzt. <\/p>\n Eine SQL Server-Datenbank besteht also mindestens aus zwei Dateien: einer Datendatei, in der die Daten der Datenbank gespeichert werden (MDF), und der Protokolldatei (LDF). Die Daten der Datenbank können noch auf weitere Datenbankdateien (NDF) verteilt werden. <\/p>\n Access dagegen speichert die Daten nur in einer Datei ab – der MDB. <\/p>\n Sofern Datenbankprobleme in Access mit dem Tool „Reparieren und Komprimieren“ nicht behoben werden können, bleibt nur die Wiederherstellung der letzten Sicherung.<\/p>\n Dies bedeutet aber einen Datenverlust vom Zeitpunkt der letzten Sicherung bis hin zum Zeitpunkt des Datenbankproblems – sofern überhaupt eine aktuelle Sicherung vorliegt.<\/p>\n Handelt es sich bei der Datenbank um eine reine Client-Installation, wird diese wohl eher nicht regelmäßig gesichert. Backup-Szenarien sind meist Servern vorbehalten und einzelne Clients werden dabei selten berücksichtigt.<\/p>\n Liegt die Access-Datenbank auf einem Netzlaufwerk, ist die Wahrscheinlichkeit, dass die Datenbank regelmäßig gesichert wird, schon weitaus höher. Sofern mit der Datenbank nicht gerade gearbeitet wird, denn eine Sicherung im laufenden Betrieb – sprich während die Datenbank genutzt wird – ist bei Access ein unsicheres Unterfangen.<\/p>\n Der SQL Server lässt die Sicherung einer Datenbank auch während des laufenden Betriebs zu. Dazu nutzt er einen eigenen Sicherungsmechanismus, der Backup-Dateien erzeugt und diese auf Festplatten, Bändern oder ähnlichen Medien speichert. <\/p>\n Ein SQL Server ist darauf ausgelegt, dass die Datenbanken permanent zur Verfügung stehen. Die Anforderungen „24\/7“-Betrieb oder „Always on, always available“ werden erfüllt.<\/p>\n Die Datenbanksicherung des SQL Servers unterscheidet sich nicht nur in der Art der Ausführung, sondern auch im Inhalt. Während bei Access die komplette Datei zu einem bestimmten Zeitpunkt gesichert bzw. kopiert wird, kann der SQL Server die einzelnen Datenbankaktionen – die Transaktionen – mit der Transaktionsprotokollsicherung sichern. Dadurch ist es möglich, die Daten einer Datenbank bis zum Zeitpunkt der letzten Transaktionsprotokollsicherung wiederherzustellen. <\/p>\n Dazu ein kleines Beispiel: Für eine SQL Server-Datenbank wird eine tägliche Vollsicherung um 1.00 Uhr nachts und zusätzlich im Zeitraum von 5.00 Uhr und 23:00 Uhr alle 15 Minuten eine Transaktionsprotokollsicherung durchgeführt. Durch einen Hardwarefehler um 15:05 Uhr ist die Datenbank eines SQL Servers nicht mehr verfügbar. Mit der Vollsicherung und den Transaktionsprotokollsicherungen kann die Datenbank bis zum Zeitpunkt 15:00 Uhr wiederhergestellt werden. Sofern es nach dem Hardwarefehler noch möglich ist, die Transaktionsprotokolldatei zu sichern, ist sogar eine Wiederherstellung bis zum Eintreten des Fehlers möglich. <\/p>\n Die Datenbanksicherung ist nicht die einzige Methode, die SQL Server zur Sicherung der Daten anbietet. Es gibt verschiedene Tools, um eine permanente Verfügbarkeit zu gewährleisten. Mit Standby-Servern, Logshipping, Datenbankspiegelung und Datenbank-Cluster stehen viele Methoden und Funktionen zum Thema Ausfallsicherheit zur Verfügung.<\/p>\n Ein weiterer Aspekt der Datensicherheit ist die Sicherung der Daten vor fremdem Zugriff. Und mit Zugriff ist an dieser Stelle nicht der Zugriff auf einzelne Datensätze, sondern der Zugriff in die eigene Tasche gemeint: USB-Stick einstöpseln, Access-Datenbank (mdb) kopieren und schon sind wichtige Unternehmensdaten in fremden Händen.<\/p>\n Sicher kann eine Access-Datenbank vor fremdem Zugriff mit dem Datenbank-Kennwort oder einer Arbeitsgruppen-Informationsdatei (MDW) geschützt werden, doch zum Knacken dieser Schutzmechanismen kursieren im Internet diverse Cracktools.<\/p>\n Die Datenbank eines SQL Servers kann nicht einfach kopiert werden, da der SQL Server-Dienst permanent auf die Datenbank zugreift. Und selbst wenn eine Backup-Datei einer SQL Server-Datenbank auf illegale Weise den Besitzer wechseln würde, werden für die Wiederherstellung der Datenbank die Daten der Logins und Benutzer benötigt. Diese werden nicht wie bei Access in einer Arbeitsgruppen-Informationsdatei gespeichert. <\/p>\n SQL Server bietet eine mehrstufige Sicherheitsarchitektur, bei der zwischen Authentifizierung und Autorisierung unterschieden wird. Für jeden Zugriff auf die Daten einer Datenbank findet zunächst eine Authentifizierung des Benutzers am SQL Server statt, gefolgt von der Autorisierung für die jeweilige Datenbank. <\/p>\n Für die Authentifizierung des Benutzers am SQL Server stehen zwei Authentifizierungsmethoden zur Verfügung: Die SQL Server-Authentifizierung und die Windows-Authentifizierung. Beide Verfahren prüfen eine Login-ID, die mit der Anmeldung übergeben wird. Bei der Windows-Authentifizierung wird die Login-ID des Benutzernamens der Windows- bzw. Domänenanmeldung vom Betriebssystem geprüft, während für die SQL Server-Authentifizierung vom Betriebssystem unabhängige Login-IDs geprüft werden, die im SQL Server selbst verwaltet werden.<\/p>\n Die Autorisierung regelt den Zugriff jeder einzelnen Login-ID auf die jeweiligen Datenbanken. Dabei erhält jede Login-ID für jede Datenbank eine weitere ID: die Benutzer-ID. über die Benutzer-ID werden die Rechte für die jeweilige Datenbank geregelt.<\/p>\n Die Rechte zum Lesen, ändern, Löschen bzw. Hinzufügen von Daten können dezidiert an Tabellen und auch an Spalten vergeben werden. Ein Benutzer, der die Daten einer Tabelle lesen darf, darf diese nicht zwangsläufig auch ändern. Dazu kommen Rechte zum Erstellen von Datenbankobjekten wie Tabellen, Sichten oder für das Ausführen von gespeicherten Prozeduren und viele andere mehr.<\/p>\n Der SQL Server bietet mit dieser mehrstufigen Sicherheitsarchitektur nicht nur eine gute Absicherung der Daten vor fremdem Zugriff, sondern geht sogar noch einen Schritt weiter. <\/p>\n Die Daten einer SQL Server-Datenbank können nicht nur verschlüsselt gespeichert werden, auch die übertragung der Daten vom Client zum Datenbank-Server kann verschlüsselt erfolgen. Ein „Mithören“ der Datenübertragung liefert in diesem Fall nur Kauderwelsch.<\/p>\n Gerade die Datenübertragung wird bei SQL Server-Datenbanken zunehmen, denn die Daten der Datenbank können nicht nur einer Applikation, sondern mehreren Applikationen zur Verfügung stehen. SQL Server-Datenbanken sind weitaus flexibler als Access-Datenbanken einsetzbar.<\/p>\n Die Programmlogik zur Verwaltung der Daten in einer Access-Datenbank wird mit Formularen, Berichten, Abfragen und Modulen umgesetzt. Diese Objekte stehen nur in Access zur Verfügung. Weder die Formulare, noch die Berichte, Abfragen oder Module sind eigenständig und können in anderen Applikationen wieder verwendet werden – mühsames Kopieren und Einfügen mal ausgenommen.<\/p>\n Das schränkt die Flexibilität einer Access-Datenbank stark ein. Natürlich können die Daten ausgelagert in einer eigenen Access-Datenbank anderen Applikationen zur Verfügung gestellt werden. Doch das mindert die redundante Programmierarbeit nur minimal, da für jede Applikation die Programmlogik erneut programmiert werden muss. <\/p>\n In einer SQL Server-Datenbank kann die Programmlogik zu weiten Teilen mit gespeicherten Prozeduren, benutzerdefinierten Funktionen und Triggern abgebildet werden. Durch einen konsequenten Einsatz dieser Objekte gehen alle Datenänderungsvorgänge immer ein und denselben Weg. Die entsprechenden Applikationen nutzen lediglich die jeweiligen Datenbankobjekte zum ändern, Löschen oder Hinzufügen von Daten.<\/p>\n Sollte sich die Programmlogik ändern, müssen nur die entsprechenden Datenbankobjekte an die änderungen angepasst werden. Mit einer stringenten Berechtigungsvergabe können direkte Datenänderungen in den Tabellen gesperrt werden, sodass nur der Weg über die Datenbankobjekte mit der entsprechenden Programmlogik möglich ist.<\/p>\n Nun haben Sie verschiedene Gründe für den Wechsel von Access auf SQL Server kennen gelernt. Auch wenn Ihre Access-Applikation noch schnell und sicher ihre Dienste tut, kann es doch aus Gründen der Skalierbarkeit, der Daten- und Ausfallsicherheit, der Zugriffsberechtigungen oder der Flexibilität notwendig sein, zum SQL Server zu wechseln.<\/p>\n Vielleicht aber profitieren Sie eher von den vielen verschiedenen Tools des SQL Servers wie dem MS Profiler für Performance-Optimierung und dem Analysieren des Abfrageverhaltens, den Reporting Services für die Einführung eines zentralen Berichtswesens, den Integration Services für Datenmigration, den Analysis Services für Auswertungen im Business Intelligence Bereich oder den vielen weiteren Tools des SQL Servers.<\/p>\n Es gibt viele Gründe für einen Wechsel – doch der Umstieg ist nicht immer einfach. SQL Server unterscheidet sich in vielen Punkten immens von Access. Dazu werden Sie in den nächsten Ausgaben an dieser Stelle mehr erfahren.<\/p>\n","protected":false},"excerpt":{"rendered":" „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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662007,66042007,44000040,44000022,44000020],"tags":[],"class_list":["post-55000472","post","type-post","status-publish","format-standard","hentry","category-662007","category-66042007","category-Allgemein","category-SQL_Server_und_Co","category-Tools"],"yoast_head":"\n\nDateiserver vs. Client\/Server <\/h2>\n
Performance<\/h2>\n
Skalierbarkeit<\/h2>\n
Stabilität und Sicherheit<\/h2>\n
Flexibilität<\/h2>\n
Fazit<\/h2>\n