Zum Vergleich: ACCESS VS. SQL-SERVER VS. MYSQL

Zum Vergleich: ACCESS VS. SQL-SERVER VS. MYSQL

Kleine Entscheidungshilfe Access vs. SQL-Server vs. mySQL               -> PDF download

Für die meisten allgemeinen Verwaltungsaufgaben werden Sie mit einer Access-Datenbank in Hinsicht auf die Größe und “Menge” an zu erwartenden Daten ausreichend versorgt sein. Wenn sich Ihre Anforderungen an Ihre Datenbank jedoch ändern, sollten Sie überlegen, ob sich der Einsatz eines wesentlich schnelleren, flexibleren und sichereren Datenbank-Systems als “Back-End” lohnen könnte. Sie könnten z.B. Ihre Access Anwendung als „Front-End“ weiter verwenden und lediglich die Backend-Seite auf SQL-Server umstellen.

Als Alternative steht auch mySQL zur Verfügung. Als wesentlicher Aspekt kann hier das Kostenargument gelten. MySQL ist grundsätzlich kostenlos (open-source), für die kommerzielle Nutzung fallen – wenn überhaupt – minimale Lizenzgebühren an. MySQL eignet sich besonders als Online-Datenbanksystem. Für die Steuerung können Front-End-Programme (auch Access) verwendet werden (Access allerdings nicht ohne Probleme). Zugriff und Steuerung auf eine mySQL-Datenbank wird allerdings bevorzugt – aber nicht notwendigerweise – über einen Browser vorgenommen. Die Programmierung findet über HTML/PHP, Perl, Java oder dergleichen statt. Im Gegensatz zu Access und SQL-Server ist es erforderlich, zusätzliche Steuerungs-Tools zu installieren (bsp: SQL-Administrator, Control-Center, Query-Browser, SQLYog etc.)
SQL-Server Express (SSE)

Seit der Version SQL-Server 2005 stellt Microsoft als Nachfolge zur MSDE (Microsoft-Database-Engine) die etwas abgespeckte Version SQL-Server-Express (SSE) zum download zur Verfügung. Im Gegensatz zu MSDE, die auf 2GB beschränkt war, sind in dieser Nachfolgeversion nun immerhin 4GB verfügbar. Diese Version kann überdies 1GB Arbeitsspeicher adressieren. Ähnlich wie bei mySql sollten hier weitere Tools installiert werden, da die Administration ansonsten äußerst umständlich ausfällt. Im Wesentlichen sei hier „Management Studio Express“ (ähnlich dem Enterprise-Manager) erwähnt. SQL Express erwartet außerdem die Installation von Dotnet-Framework 2.0f auf dem Server. Vermutlich als Konkurrenz zu mySql ist diese Version von Sql-Server auch als Online-Datenbank konzipiert, kann aber zumindest gut verwendet werden, um eine Online-Datenbank offline vorzubereiten (die Online-Datenbank wird oft bei einem Provider “gemietet”).

Zur “Vorbereitung” einer SQL-Server-Datenbank (oder auch mehrerer) kann auch die SQL-Server-Developer-Edition verwendet werden, die zwar nicht mehr kostenlos aber immer noch deutlich(!) günstiger zu erwerben ist als die Vollversion, zudem müssen hier keine weiteren Tools installiert werden wie bei SSE.
Das Framework (dotnetfx.exe), die Datenbank (SQLEXPR.exe) als auch das Management Studio (SQLServer2005_SSMEE.msi) sind bei MS frei also kostenlos verfügbar.
[Literatur-Empfehlung zum Thema SSE: „SQL-Server Express Edition“ von Andreas Kosch]

Weiterhin bietet Microsoft den SQL-Server-Compact an

Migration / Import von Daten in SSE
Für die Migration / Import (einspielen bzw. Übernahme) von Access-Daten stellt MS ein Tool zur Verfügung: SQL Server Migration Assistant for Access (SSMA Access)
und ist zum Zeitpunkt der Erstellung dieses Berichts HIER erhältlich.

Nach dem Download, wird eine Licence-Registration fällig, die aber ebenfalls bei MS erhältlich ist. Die Licence-Datei wird lokal gespeichert und beim ersten Programmstart abgefragt (und sollte anschließend nicht gelöscht werden).

Wichtig bei der Migration: die Quelldaten sollten hinsichtlich der Spalten- bzw. Feldnamen den allgemeinen internationalen Standards entsprechen und keine Sonderzeichen beinhalten – auch nicht Minuszeichen und dergleichen – siehe hierzu meinen Bericht unter Feldnamen_Empfehlungen.pdf


Seit der Version Access 2007 aus Office-2007 ändert sich hinsichtlich der bisherigen Verfahren bei Access so einiges. Bei den ersten Beta-Versionen hatte ich noch den Eindruck, dass sich die ganze Office-Palette (einschließlich Excel) so allmählich entwicklerunfreundlich gestaltet, aber mittlerweile scheint sich der erste Eindruck nicht zwingend zu verdichten. Der Schwerpunkt verlagert sich jedoch recht erheblich. Zwar geht es auch weiterhin um „Datenbanken“, jetzt aber nicht mehr so begrenzt auf .MDB-Dateien (bzw. .ACCDB bei Access 2007 und 2010) mit den üblichen Verknüpfungen und Importen. Eher geht darum „multifunktional“ Daten aus unterschiedlichsten Quellen einzulinken und möglichst variabel darzustellen. Auch Autofilter, die ansonsten Excel vorbehalten waren, finden jetzt ihre Entsprechung. Die Datenbank-Erstellung im „konventionellen“ (und auch weiterhin absolut unverzichtbaren) Sinne wird in Zukunft eher auf SQL-Server(-Express) und DotNet (.Net) ausgelagert.

Besonders erwähnenswert ist, dass Microsoft mit der Version 2007 für Access eine Runtime-Version zur Verfügung stellt, die kostenlos(!!) aus dem Netz geladen und ohne Aufwand installiert werden kann. Somit können Anwendungen erstellt werden, die auf dem Ausführungsrechner keine Installation von Access erfordert. Dieses Runtime-Tool war bei den Vorläufer-Versionen (also bis 2003) recht kostenaufwändig gesondert zu erwerben.

Access-Datenbank im Web: Office Access 2007 enthält nur begrenzte Unterstützung für das Freigeben einer Datenbank im Web (nur die Veröffentlichung von Listen verschieben der Datenbank in Dokumentbibliotheken). In Access 2010 dagegen können Sie eine Webdatenbank erstellen (wenn Sie Zugriff auf Access Services in Microsoft SharePoint Server 2010 haben). Benutzer können die Datenbank dann in einem Webbrowserfenster verwenden. Änderungen am Entwurf erfordern jedoch Access 2010. Obacht: Einige Features für Desktopdatenbanken sind nicht auf das Web übertragbar – es können viele der gleichen Aufgaben mithilfe neuer Features ausgeführt werden (beispielsweise berechnete Felder und Datenmakros).

Hier einige Hinweise zur Entscheidungshilfe für eine eventuelle Umstellung:
Datenimport / -export:

  • SQL-Server: Bestehende Datenbestände können mit Hilfe der Import-Assistenten (Data-Transfer-Service) bzw. dem Integration-Services in eine SQL-Datenbank importiert / exportiert werden
  • SQL-Server-Express: nach einer Installation zunächst nicht verfügbar, allerdings können die oben erwähnten SSMA-Tools für Importe verwendet werden
  • Access: Es existieren die Standard Office-Konverter und die ODBC-Schnittstelle.
    mySQL: Es existieren Konverter und die ODBC-Schnittstelle (ist gesondert zu installieren).

Sicherungsverfahren (siehe dazu auch weiter unten unter “Datensicherheit, Performance und Weiterverwendung”):

  • SQL-Server: Sicherungen können automatisiert (z.B zeitgesteuert) werden.
  • SQL-Server-Express existiert das Backup-Divices-Tool und kann ebenfalls zeitgesteuert eingestellt werden
  • Access: Sicherungen und evtl. Wiederherstellungen müssen von Hand gesteuert oder Sicherungsverfahren programmiert werden.
  • mySQL: Sicherungen und evtl. Wiederherstellungen müssen von Hand gesteuert oder Sicherungsverfahren programmiert werden.

Installation:

  • SQL-Server: Eine Serverinstallation; Client-Tools auf den Benutzerrechnern.
  • SQL-Server-Express: desgleichen
  • Access: Auf jeden Rechner eine Access- oder eine Runtime-Installation.
  • mySQL: Server- Client-Installation mit Benutzerrechten.

Benutzerverwaltung:

  • SQL-Server: es kann eine nahezu beliebige Anzahl von Benutzern für alle Datenbanken auf dem Server verwaltet werden. Die Zugriffsrechte können für jede Datenbank, jede Tabelle und auf Spaltenebene definiert werden.
  • SQL-Server-Express: Anmeldung wird über Security-Logins bzw Security-users der jeweiligen Datenbank und der Server- und Database-Roles verwaltet
  • Access: Es existieren die Access-Benutzer-Verwaltungs-Modalitäten für jede Datenbank einzeln. Zugriffbeschränkungen können nicht auf Spaltenebene definiert werden.
  • mySQL: Ähnlich wie SQL-Server.

Datenbestände:

  • SQL-Server: Der Datenbestand kann ohne Verlust von Geschwindigkeit ausgedehnt werden. Datenbestände können problemlos im Terabyte-Bereich verwaltet werden. SQL-Datenbanken sind fast frei skalierbar. Sie können Ihre Daten auch mit anderen Systemen nutzen, die Abfragesprache SQL ist systemübergreifend. Es können beliebig viele Datenbanken definiert werden. -SQL-Server-Express: max 4GB.
  • Access: Eine Datenbank erfasst max. 2GB Daten (bei abnehmender Geschwindigkeit). In eine Access-Tabelle können Sie max. 2.147 Mrd. Datensätze erfassen; das ist zwar für nahezu alle Datenbanken im Verwaltungsbereich vollkommen ausreichend, wenn Sie allerdings einen bestimmten Datenbestand erreicht haben (der nicht genau zu bestimmen ist, ist abhängig von der Hardware sowie vom Netz und Netztransfer), wird Access als interpretierendes System sehr langsam, um nicht zu sagen unerträglich
  • mySQL: .es existieren verschiedene Tabellen-Typen (MyIsam, InnoDB…). Die Datenbanken sind fast frei skalierbar. SQL entspricht mit leichten Einschränkungen der Standard-Norm. Es sind beliebig viele Datenbanken definierbar.

Ein wesentlicher Punkt ist der Datentransfer:

  • SQL-Server: führt die Abfrage auf dem Server aus und transferiert lediglich die selektierten Daten zumindest dann, wenn “direkt auf dem Server” programmiert werden kann, wenn also Abfragen/gespeicherte Prozeduren “in der Datenbank” abgelegt werden können. Alternativ bietet sich noch die Möglichkeit eine ODBC1-Schnittstelle für den Zugriff auf die Daten zu verwenden
  • SQL-Server-Express: wie SQL-Server
  • Access: Bei einer Access-Abfrage werden zum Ausführen einer Abfrage ALLE Daten über das Netz transferiert und lokal selektiert.
  • Das kann dazu führen, dass eine Abfrage, die sich auf einen Datenbestand von z.B. 200.000 Zeilen bezieht und 5.000 selektiert, bei einer Access-Datenbank das System für längere Zeit stark belastet, während SQL-Server damit keine Probleme hat.
  • mySQL: Bei einer Abfrage werden zum Ausführen einer Abfrage alle Daten vorselektiert.

Ein weiterer wesentlicher Punkt ist die Komprimierung:

  • SQL-Server: Die Daten liegen immer komprimiert vor.
  • SQL-Server-Express: wie SQL-Server
  • Access: In einer Access-Datenbank werden gelöschte Datensätze mit einem “Gelöscht”-Kennzeichen geführt und erst dann physisch aus der Datenbank entfernt, wenn die Datendatei komprimiert wird (Im Menü: Datenbank-Dienstprogramme: Komprimieren und reparieren). Dieser Komprimierungsvorgang sollte regelmäßig vorgenommen werden. Das hat sich in der Version 2007 und sogar in 2010 (auch ACCDB) leider immer noch nicht geändert
  • mySQL: Die Daten liegen grundsätzlich komprimiert vor. Bei der Verwendung von Dynamic- Tabellen (häufige Verwendung) sollte allerdings gelegentlich von Hand komprimiert werden.

Outer Joins:

  • SQL-Server: Left-Join und Right-Join; zusätzlich Full-Join
  • SQL-Server-Express: wie SQL-Server
  • Access: Left-Join und Right-Join
  • mySQL: Left-Join und Right-Join, zusätzlich Full-Join

Sicherheit:

  • SQL-Server: Alle Zugriffe werden protokolliert und können nachvollzogen werden
    SQL-Server-Express: Server-Logs werden protokolliert
    Access: keine Protokolle
    mySQL: Logging kann aktiviert werden, verlangsamt allerdings den DB-Betrieb.

Multi-User-Fähigkeit:

  • SQL-Server: als serverbasiertes Datenbanksystem stehen alle Möglichkeiten der Multiuser-Fähigkeit zur Verfügung
  • SQL-Server-Express: wie SQL-Server, es gelten eingeschränkte Spezifikationen (siehe unter msdn-online.de)
  • Access: Multiuserfähigkeit u.a. mit der Einschränkung des Datentransfer-Geschwindigkeitsproblems.
  • mySQL: Volle Multiuserfähig; spezielle Web-Tauglichkeit
1 ODBC: Open-database-connectivity (wird über die Systemsteuerung lokal vorgeommen)

Letzter Zugriff:

  • SQL-Server: kann mittels timestamp-Spalten (millisekundengenaue Erfassung des letzten Zugriffs) gesteuert werden
  • SQL-Server-Express: timestamp-Spalte wie SQL-Server
  • Access: keine Möglichkeit vorgesehen, kann aber über Modul-Funktionen abgefragt bzw. ausgelesen werden
  • mySQL: timestamp-Spalten wie SQL-Server.

Wartung / Aufwand /Schulung:

  • SQL-Server: Backups, Importe, Exporte und dergleichen sind einstellbar; Fachpersonal muss ggf. geschult oder akquiriert werden.
  • SQL-Server-Express: Backups sind einstellbar, es existiert aber kein DTS (data-transfer-service) bzw. Integration-Services, Fachpersonal sollte geschult oder akquiriert werden
  • Access: Kann ggf. auch von Office-Personal bedient werden. Aber Obacht: Die Erstellung einer Datenbank erfordert Erfahrung (und Weitsicht) und wird nicht einfach aus dem Ärmel geschüttelt. Häufig treten tief greifende Probleme erst später in Erscheinung, angefangen bei der Vergabe von Spaltennamen (bzw. Feldnamen) und noch lange nicht aufgehört bei der Normalisierung.
  • mySQL: Fachpersonal insbesondere für die Zugriffssteuerung und Programmierung erforderlich.

Mein Fazit zum Thema Access:
Über Access wird viel herumgeunkt. Was die Back-End-Verwendung betrifft kann ich die Ansicht grundsätzlich teilen, was die Front-End-seitige Verwendung betrifft eher nicht.
Die Back-End-Verwendung: Man stelle sich nur vor: Eine Daten-Back-End-Datei kann im Explorer mit der Entfernten-Taste einfach gelöscht werden!! Der datentechnische Super-GAU! Eine SQL-Server-Datenbank löscht man nicht einfach mit der Entf-Taste, zumal in der Regel nur legitimiertes Personal an die Entwicklungsumgebung des SQL-Servers herankommt.

Andererseits: gerade kürzlich habe ich wieder einen Fall erlebt, bei dem ein Mitarbeiter einer großen norddeutschen Bank mit meiner Unterstützung eine Datenbank zu einem bestimmten Controlling-Thema erstellt hat und zwar mit einer MDB als Frontend UND als Backend. Innerhalb kürzester Zeit (einige Wochen) würde offenbar, dass er hier etwas “Wertvolles” (ein Tool mit hoher Aussagerelevanz) entwickelt und die Datenbank wurde (schon aus den schnell erkanten Sicherheitsgründen) in eine sichere Umgebung überführt. Hätte der Mitarbeiter erst die IT-Abteilung mit dieser Problematik beauftragt, wäre daraus wohl in den nächsten Jahren nichts geworden.

Also: Access ist ein hervorragendes (und relativ einfaches) Programm zu Problemverdeutlichung. Es besteht die Möglichkeit eine Datenbank ohne allzu großen Aufwand “erstmal” zu erstellen (was nicht darüber hinwegtäuschen soll, dass – wie weiter oben bereits erwähnt – jede Datenbank – auch eine MDB (bzw. .ACCDB bei Access 2007 und 2010) – mit Weitsicht und vertiefender Kenntnis erstellt werden muss).

Zur Front-End-Verwendung: Wie erwähnt (siehe hierzu auch weiter unten) kann Access auch als Front-End-Programm “relativ” einfach programmiert werden (vorzugsweise unter Anbindung eines “vernünftigen” Back-End-Systems). Jetzt kommt es natürlich noch darauf zu definieren, wie DAU-sicher die Anwendung sein soll. Im Regefall sollte das selbstverständlich sein. Hier sind verschiedene Einstellungen vorzunehmen wie z.B. die Vermeidung eine Front-End-MDB einfach mit gedrückt gehaltener Shift-Taste einfach im Entwicklungsmodus zu öffnen und dergleichen.

Also: Access als Front-End: JA; als Back-End – auf Dauer -: NEIN

Datensicherheit, Performance und Weiterverwendung
Eine Datensicherung kann in Access leider nicht automatisiert eingestellt werden, da es sich bei MDB- bzw. ACCDB-Dateien lediglich um komplexere Dateien handelt, aber nicht um einen Datenbankserver. Eine Datensicherung muss daher leider von Hand durchgeführt werden, oder über einen Laufwerk-Sicherungslauf vorgenommen werden, was z.B. mit dem Laufwerk V: (auf dem eine Backend-MDB- oder ACCDB-Datei aufgespielt sein könnte) eingestellt ist. Eine deutlich bessere Möglichkeit, relevante Daten zu führen wäre es, die Daten (schon aufgrund ihrer Relevanz) in einem SQL-Server zu überführen und die Access-Frontend-Datei z.B. mit einer ODBC-Schnittstelle an diese Datenbank anzubinden.

Somit würden sich folgenden Vorteile ergeben:
1. Datensicherheit: Die Zugriff-Legitimierung auf die Daten kann über die Benutzersteuerung des SQL-Server eingestellt werden, z.B. mittels der Windows-Autenzifizierung
2. Datensicherung: Ein SQL-Server ist hinsichtlich der Datensicherung einstellbar und wird von Datenbankadministratoren vor Ort verwaltet
3. Komprimierungsverlust: SQL-Server speichert die Daten stets komprimiert, eine händische Komprimierung entfällt
4. Daten-”Mengen” und Performance: Für Access-Dateien gilt eine begrenzte Dateigröße, die zwar mit “üblichen” Verwaltungs-Daten nicht so schnell erreicht werden, aber je größer die Datei, desto geringer die Performance bzw. desto langsamer der Zugriff und Datentransfer. SQL-Server-Datenbanken sind frei skalierbar, Performance-Probleme sind nicht zu erwarten
5. Übergreifende Verwendung der Daten: Die Daten verfügen ggf. über die Relevanz langfristig auch mit anderen Datenbanken in Verbindung gebracht und ausgewertet werden zu können. Davon ausgehend, dass auf einem Server auch andre Daten abgelegt werden, ist eine Verknüpfung dieser Daten technische relativ einfach zu erreichen.
6. Zukunftsgerichtete Verwendung: Während sich MDB- bzw. ACCDB-Dateien als Datenbestandsführung in irgend absehbarer technisch erledigen dürften, kann davon ausgegangen werden, dass SQL-Server-Daten(banken) zukunftsfähig und für eine eventuelle Umstellung auf ein anderes Frontend geeignet sind. Auch z.B. ein browsergesteuerter Zugriff (Stichwort “Intranet”) ist schnell einzurichten.
7. Weiternutzung eines Access-Frontend bei Umstellung einer MBD bzw. ACCDB-Datendatei: Die Datenbank kann wie gewohnt weiterverwendet werden. Es sind lediglich folgende Umprogrammierungen vorzunehmen:
a. ggf. Anpassung der Feldnamen an die Richtlinien von SQL-Server
b. Umwandeln der Backend-Datei in eine SQL-Server-Datenbank – dafür gibt es Integration-Service-Tools mit denen der Vorgang automatisiert werden kann – bedenken Sie aber bitte, dass es in den allermeisten Fällen geradezu zwingend ist, in jeder Tabelle eine TimeStamp-Spalte mit aufzunehmen!
c. Anpassen eventuell geänderter Felder/Spalten in den Steuerungsformularen/Abfragen/Berichten/Codes
d. Anpassen der Abfragen in Hinsicht auf boolsche Felder Hinweis zu den boolschen Feldern: SQL-Server-Datentabellen verwenden im Gegensatz zu Access Ja/Nein-Feldern drei Zustände anstatt zwei: true, false und null das bedeutet, dass eine Abfrage (query) mitunter derart angepasst werden muss, dass es in den Kriterien heisst “…WHERE boolschesFeld = False or boolsches Feld IS NULL”
e. Anpassung des Codes in Hinsicht auf die Datenzugriffe (also die Recordsets und die OpenRecordset-Parameter, insbesondere der Parameter bzw die Konstante dbSeeChanges)
f. Erstellung einer lokalen ODBC-Verknüpfung auf allen Rechnern, auf denen die Datenbank genutzt werden soll – es sei denn die ganze Geschichte läuft über eine Citrix-Umgebung, hier gelten etwas andere Regeln: Die ODBC-Verknüpfung wird hier in der Regel im Profil angelegt.
g. Erstellung einer ODBC-Autoverknüpfung beim Start der Datenbank (Programmierung einer “Autostart”-Funktion, die den Link bzw. Connect zur Datenbank untersucht bzw. überprüft und bei Erfolg anlinkt)
h. Die Benutzer müssten in der SQL-Server Benutzertabelle geführt werden

[compare].Access vs. SQL-Server vs. mySql

Kleine Entscheidungshilfe Access vs. SQL-Server vs. mySQL

Für die meisten allgemeinen Verwaltungsaufgaben werden Sie mit einer Access-Datenbank in Hinsicht auf die Größe und „Menge“ an zu erwartenden Daten ausreichend versorgt sein. Wenn sich Ihre Anforderungen an Ihre Datenbank jedoch ändern, sollten Sie überlegen, ob sich der Einsatz eines wesentlich schnelleren, flexibleren und sichereren Datenbank-Systems als „Back-End“ lohnen könnte. Sie könnten z.B. Ihre Access Anwendung als „Front-End“ weiter verwenden und lediglich die Backend-Seite auf SQL-Server umstellen.

Als Alternative steht auch mySQL zur Verfügung. Als wesentlicher Aspekt kann hier das Kostenargument gelten. MySQL ist grundsätzlich kostenlos (open-source), für die kommerzielle Nutzung fallen – wenn überhaupt – minimale Lizenzgebühren an. MySQL eignet sich besonders als Online-Datenbanksystem. Für die Steuerung können Front-End-Programme (auch Access) verwendet werden (Access allerdings nicht ohne Probleme). Zugriff und Steuerung auf eine mySQL-Datenbank wird allerdings bevorzugt – aber nicht notwendigerweise – über einen Browser vorgenommen. Die Programmierung findet über HTML/PHP, Perl, Java oder dergleichen statt. Im Gegensatz zu Access und SQL-Server ist es erforderlich, zusätzliche Steuerungs-Tools zu installieren (bsp: SQL-Administrator, Control-Center, Query-Browser, SQLYog etc.)
SQL-Server Express (SSE)

Seit der Version SQL-Server 2005 stellt Microsoft als Nachfolge zur MSDE (Microsoft-Database-Engine) die etwas abgespeckte Version SQL-Server-Express (SSE) zum download zur Verfügung. Im Gegensatz zu MSDE, die auf 2GB beschränkt war, sind in dieser Nachfolgeversion nun immerhin 4GB verfügbar. Diese Version kann überdies 1GB Arbeitsspeicher adressieren. Ähnlich wie bei mySql sollten hier weitere Tools installiert werden, da die Administration ansonsten äußerst umständlich ausfällt. Im Wesentlichen sei hier „Management Studio Express“ (ähnlich dem Enterprise-Manager) erwähnt. SQL Express erwartet außerdem die Installation von Dotnet-Framework 2.0f auf dem Server. Vermutlich als Konkurrenz zu mySql ist diese Version von Sql-Server auch als Online-Datenbank konzipiert, kann aber zumindest gut verwendet werden, um eine Online-Datenbank offline vorzubereiten (die Online-Datenbank wird oft bei einem Provider „gemietet“).

Zur „Vorbereitung“ einer SQL-Server-Datenbank (oder auch mehrerer) kann auch die SQL-Server-Developer-Edition verwendet werden, die zwar nicht mehr kostenlos aber immer noch deutlich(!) günstiger zu erwerben ist als die Vollversion, zudem müssen hier keine weiteren Tools installiert werden wie bei SSE.
Das Framework (dotnetfx.exe), die Datenbank (SQLEXPR.exe) als auch das Management Studio (SQLServer2005_SSMEE.msi) sind bei MS frei also kostenlos verfügbar.
[Literatur-Empfehlung zum Thema SSE: „SQL-Server Express Edition“ von Andreas Kosch]

Weiterhin bietet Microsoft den SQL-Server-Compact an

Migration / Import von Daten in SSE
Für die Migration / Import (einspielen bzw. Übernahme) von Access-Daten stellt MS ein Tool zur Verfügung: SQL Server Migration Assistant for Access (SSMA Access)
und ist zum Zeitpunkt der Erstellung dieses Berichts HIER erhältlich.

Nach dem Download, wird eine Licence-Registration fällig, die aber ebenfalls bei MS erhältlich ist. Die Licence-Datei wird lokal gespeichert und beim ersten Programmstart abgefragt (und sollte anschließend nicht gelöscht werden).

Wichtig bei der Migration: die Quelldaten sollten hinsichtlich der Spalten- bzw. Feldnamen den allgemeinen internationalen Standards entsprechen und keine Sonderzeichen beinhalten – auch nicht Minuszeichen und dergleichen – siehe hierzu meinen Bericht unter Feldnamen_Empfehlungen.pdf


Seit der Version Access 2007 aus Office-2007 ändert sich hinsichtlich der bisherigen Verfahren bei Access so einiges. Bei den ersten Beta-Versionen hatte ich noch den Eindruck, dass sich die ganze Office-Palette (einschließlich Excel) so allmählich entwicklerunfreundlich gestaltet, aber mittlerweile scheint sich der erste Eindruck nicht zwingend zu verdichten. Der Schwerpunkt verlagert sich jedoch recht erheblich. Zwar geht es auch weiterhin um „Datenbanken“, jetzt aber nicht mehr so begrenzt auf .MDB-Dateien (bzw. .ACCDB bei Access 2007 und 2010) mit den üblichen Verknüpfungen und Importen. Eher geht darum „multifunktional“ Daten aus unterschiedlichsten Quellen einzulinken und möglichst variabel darzustellen. Auch Autofilter, die ansonsten Excel vorbehalten waren, finden jetzt ihre Entsprechung. Die Datenbank-Erstellung im „konventionellen“ (und auch weiterhin absolut unverzichtbaren) Sinne wird in Zukunft eher auf SQL-Server(-Express) und DotNet (.Net) ausgelagert.

Besonders erwähnenswert ist, dass Microsoft mit der Version 2007 für Access eine Runtime-Version zur Verfügung stellt, die kostenlos(!!) aus dem Netz geladen und ohne Aufwand installiert werden kann. Somit können Anwendungen erstellt werden, die auf dem Ausführungsrechner keine Installation von Access erfordert. Dieses Runtime-Tool war bei den Vorläufer-Versionen (also bis 2003) recht kostenaufwändig gesondert zu erwerben.

Access-Datenbank im Web: Office Access 2007 enthält nur begrenzte Unterstützung für das Freigeben einer Datenbank im Web (nur die Veröffentlichung von Listen verschieben der Datenbank in Dokumentbibliotheken). In Access 2010 dagegen können Sie eine Webdatenbank erstellen (wenn Sie Zugriff auf Access Services in Microsoft SharePoint Server 2010 haben). Benutzer können die Datenbank dann in einem Webbrowserfenster verwenden. Änderungen am Entwurf erfordern jedoch Access 2010. Obacht: Einige Features für Desktopdatenbanken sind nicht auf das Web übertragbar – es können viele der gleichen Aufgaben mithilfe neuer Features ausgeführt werden (beispielsweise berechnete Felder und Datenmakros).

Hier einige Hinweise zur Entscheidungshilfe für eine eventuelle Umstellung:
Datenimport / -export:

  • SQL-Server: Bestehende Datenbestände können mit Hilfe der Import-Assistenten (Data-Transfer-Service) bzw. dem Integration-Services in eine SQL-Datenbank importiert / exportiert werden
  • SQL-Server-Express: nach einer Installation zunächst nicht verfügbar, allerdings können die oben erwähnten SSMA-Tools für Importe verwendet werden
  • Access: Es existieren die Standard Office-Konverter und die ODBC-Schnittstelle.
    mySQL: Es existieren Konverter und die ODBC-Schnittstelle (ist gesondert zu installieren).

Sicherungsverfahren (siehe dazu auch weiter unten unter „Datensicherheit, Performance und Weiterverwendung“):

  • SQL-Server: Sicherungen können automatisiert (z.B zeitgesteuert) werden.
  • SQL-Server-Express existiert das Backup-Divices-Tool und kann ebenfalls zeitgesteuert eingestellt werden
  • Access: Sicherungen und evtl. Wiederherstellungen müssen von Hand gesteuert oder Sicherungsverfahren programmiert werden.
  • mySQL: Sicherungen und evtl. Wiederherstellungen müssen von Hand gesteuert oder Sicherungsverfahren programmiert werden.

Installation:

  • SQL-Server: Eine Serverinstallation; Client-Tools auf den Benutzerrechnern.
  • SQL-Server-Express: desgleichen
  • Access: Auf jeden Rechner eine Access- oder eine Runtime-Installation.
  • mySQL: Server- Client-Installation mit Benutzerrechten.

Benutzerverwaltung:

  • SQL-Server: es kann eine nahezu beliebige Anzahl von Benutzern für alle Datenbanken auf dem Server verwaltet werden. Die Zugriffsrechte können für jede Datenbank, jede Tabelle und auf Spaltenebene definiert werden.
  • SQL-Server-Express: Anmeldung wird über Security-Logins bzw Security-users der jeweiligen Datenbank und der Server- und Database-Roles verwaltet
  • Access: Es existieren die Access-Benutzer-Verwaltungs-Modalitäten für jede Datenbank einzeln. Zugriffbeschränkungen können nicht auf Spaltenebene definiert werden.
  • mySQL: Ähnlich wie SQL-Server.

Datenbestände:

  • SQL-Server: Der Datenbestand kann ohne Verlust von Geschwindigkeit ausgedehnt werden. Datenbestände können problemlos im Terabyte-Bereich verwaltet werden. SQL-Datenbanken sind fast frei skalierbar. Sie können Ihre Daten auch mit anderen Systemen nutzen, die Abfragesprache SQL ist systemübergreifend. Es können beliebig viele Datenbanken definiert werden. -SQL-Server-Express: max 4GB.
  • Access: Eine Datenbank erfasst max. 2GB Daten (bei abnehmender Geschwindigkeit). In eine Access-Tabelle können Sie max. 2.147 Mrd. Datensätze erfassen; das ist zwar für nahezu alle Datenbanken im Verwaltungsbereich vollkommen ausreichend, wenn Sie allerdings einen bestimmten Datenbestand erreicht haben (der nicht genau zu bestimmen ist, ist abhängig von der Hardware sowie vom Netz und Netztransfer), wird Access als interpretierendes System sehr langsam, um nicht zu sagen unerträglich
  • mySQL: .es existieren verschiedene Tabellen-Typen (MyIsam, InnoDB…). Die Datenbanken sind fast frei skalierbar. SQL entspricht mit leichten Einschränkungen der Standard-Norm. Es sind beliebig viele Datenbanken definierbar.

Ein wesentlicher Punkt ist der Datentransfer:

  • SQL-Server: führt die Abfrage auf dem Server aus und transferiert lediglich die selektierten Daten zumindest dann, wenn „direkt auf dem Server“ programmiert werden kann, wenn also Abfragen/gespeicherte Prozeduren „in der Datenbank“ abgelegt werden können. Alternativ bietet sich noch die Möglichkeit eine ODBC1-Schnittstelle für den Zugriff auf die Daten zu verwenden
  • SQL-Server-Express: wie SQL-Server
  • Access: Bei einer Access-Abfrage werden zum Ausführen einer Abfrage ALLE Daten über das Netz transferiert und lokal selektiert.
  • Das kann dazu führen, dass eine Abfrage, die sich auf einen Datenbestand von z.B. 200.000 Zeilen bezieht und 5.000 selektiert, bei einer Access-Datenbank das System für längere Zeit stark belastet, während SQL-Server damit keine Probleme hat.
  • mySQL: Bei einer Abfrage werden zum Ausführen einer Abfrage alle Daten vorselektiert.

Ein weiterer wesentlicher Punkt ist die Komprimierung:

  • SQL-Server: Die Daten liegen immer komprimiert vor.
  • SQL-Server-Express: wie SQL-Server
  • Access: In einer Access-Datenbank werden gelöschte Datensätze mit einem “Gelöscht”-Kennzeichen geführt und erst dann physisch aus der Datenbank entfernt, wenn die Datendatei komprimiert wird (Im Menü: Datenbank-Dienstprogramme: Komprimieren und reparieren). Dieser Komprimierungsvorgang sollte regelmäßig vorgenommen werden. Das hat sich in der Version 2007 und sogar in 2010 (auch ACCDB) leider immer noch nicht geändert
  • mySQL: Die Daten liegen grundsätzlich komprimiert vor. Bei der Verwendung von Dynamic- Tabellen (häufige Verwendung) sollte allerdings gelegentlich von Hand komprimiert werden.

Outer Joins:

  • SQL-Server: Left-Join und Right-Join; zusätzlich Full-Join
  • SQL-Server-Express: wie SQL-Server
  • Access: Left-Join und Right-Join
  • mySQL: Left-Join und Right-Join, zusätzlich Full-Join

Sicherheit:

  • SQL-Server: Alle Zugriffe werden protokolliert und können nachvollzogen werden
    SQL-Server-Express: Server-Logs werden protokolliert
    Access: keine Protokolle
    mySQL: Logging kann aktiviert werden, verlangsamt allerdings den DB-Betrieb.

Multi-User-Fähigkeit:

  • SQL-Server: als serverbasiertes Datenbanksystem stehen alle Möglichkeiten der Multiuser-Fähigkeit zur Verfügung
  • SQL-Server-Express: wie SQL-Server, es gelten eingeschränkte Spezifikationen (siehe unter msdn-online.de)
  • Access: Multiuserfähigkeit u.a. mit der Einschränkung des Datentransfer-Geschwindigkeitsproblems.
  • mySQL: Volle Multiuserfähig; spezielle Web-Tauglichkeit
1 ODBC: Open-database-connectivity (wird über die Systemsteuerung lokal vorgeommen)

Letzter Zugriff:

  • SQL-Server: kann mittels timestamp-Spalten (millisekundengenaue Erfassung des letzten Zugriffs) gesteuert werden
  • SQL-Server-Express: timestamp-Spalte wie SQL-Server
  • Access: keine Möglichkeit vorgesehen, kann aber über Modul-Funktionen abgefragt bzw. ausgelesen werden
  • mySQL: timestamp-Spalten wie SQL-Server.

Wartung / Aufwand /Schulung:

  • SQL-Server: Backups, Importe, Exporte und dergleichen sind einstellbar; Fachpersonal muss ggf. geschult oder akquiriert werden.
  • SQL-Server-Express: Backups sind einstellbar, es existiert aber kein DTS (data-transfer-service) bzw. Integration-Services, Fachpersonal sollte geschult oder akquiriert werden
  • Access: Kann ggf. auch von Office-Personal bedient werden. Aber Obacht: Die Erstellung einer Datenbank erfordert Erfahrung (und Weitsicht) und wird nicht einfach aus dem Ärmel geschüttelt. Häufig treten tief greifende Probleme erst später in Erscheinung, angefangen bei der Vergabe von Spaltennamen (bzw. Feldnamen) und noch lange nicht aufgehört bei der Normalisierung.
  • mySQL: Fachpersonal insbesondere für die Zugriffssteuerung und Programmierung erforderlich.

Mein Fazit zum Thema Access:
Über Access wird viel herumgeunkt. Was die Back-End-Verwendung betrifft kann ich die Ansicht grundsätzlich teilen, was die Front-End-seitige Verwendung betrifft eher nicht.
Die Back-End-Verwendung: Man stelle sich nur vor: Eine Daten-Back-End-Datei kann im Explorer mit der Entfernten-Taste einfach gelöscht werden!! Der datentechnische Super-GAU! Eine SQL-Server-Datenbank löscht man nicht einfach mit der Entf-Taste, zumal in der Regel nur legitimiertes Personal an die Entwicklungsumgebung des SQL-Servers herankommt.

Andererseits: gerade kürzlich habe ich wieder einen Fall erlebt, bei dem ein Mitarbeiter einer großen norddeutschen Bank mit meiner Unterstützung eine Datenbank zu einem bestimmten Controlling-Thema erstellt hat und zwar mit einer MDB als Frontend UND als Backend. Innerhalb kürzester Zeit (einige Wochen) würde offenbar, dass er hier etwas „Wertvolles“ (ein Tool mit hoher Aussagerelevanz) entwickelt und die Datenbank wurde (schon aus den schnell erkanten Sicherheitsgründen) in eine sichere Umgebung überführt. Hätte der Mitarbeiter erst die IT-Abteilung mit dieser Problematik beauftragt, wäre daraus wohl in den nächsten Jahren nichts geworden.

Also: Access ist ein hervorragendes (und relativ einfaches) Programm zu Problemverdeutlichung. Es besteht die Möglichkeit eine Datenbank ohne allzu großen Aufwand „erstmal“ zu erstellen (was nicht darüber hinwegtäuschen soll, dass – wie weiter oben bereits erwähnt – jede Datenbank – auch eine MDB (bzw. .ACCDB bei Access 2007 und 2010) – mit Weitsicht und vertiefender Kenntnis erstellt werden muss).

Zur Front-End-Verwendung: Wie erwähnt (siehe hierzu auch weiter unten) kann Access auch als Front-End-Programm „relativ“ einfach programmiert werden (vorzugsweise unter Anbindung eines „vernünftigen“ Back-End-Systems). Jetzt kommt es natürlich noch darauf zu definieren, wie DAU-sicher die Anwendung sein soll. Im Regefall sollte das selbstverständlich sein. Hier sind verschiedene Einstellungen vorzunehmen wie z.B. die Vermeidung eine Front-End-MDB einfach mit gedrückt gehaltener Shift-Taste einfach im Entwicklungsmodus zu öffnen und dergleichen.

Also: Access als Front-End: JA; als Back-End – auf Dauer -: NEIN

Datensicherheit, Performance und Weiterverwendung
Eine Datensicherung kann in Access leider nicht automatisiert eingestellt werden, da es sich bei MDB- bzw. ACCDB-Dateien lediglich um komplexere Dateien handelt, aber nicht um einen Datenbankserver. Eine Datensicherung muss daher leider von Hand durchgeführt werden, oder über einen Laufwerk-Sicherungslauf vorgenommen werden, was z.B. mit dem Laufwerk V: (auf dem eine Backend-MDB- oder ACCDB-Datei aufgespielt sein könnte) eingestellt ist. Eine deutlich bessere Möglichkeit, relevante Daten zu führen wäre es, die Daten (schon aufgrund ihrer Relevanz) in einem SQL-Server zu überführen und die Access-Frontend-Datei z.B. mit einer ODBC-Schnittstelle an diese Datenbank anzubinden.

Somit würden sich folgenden Vorteile ergeben:
1. Datensicherheit: Die Zugriff-Legitimierung auf die Daten kann über die Benutzersteuerung des SQL-Server eingestellt werden, z.B. mittels der Windows-Autenzifizierung
2. Datensicherung: Ein SQL-Server ist hinsichtlich der Datensicherung einstellbar und wird von Datenbankadministratoren vor Ort verwaltet
3. Komprimierungsverlust: SQL-Server speichert die Daten stets komprimiert, eine händische Komprimierung entfällt
4. Daten-„Mengen“ und Performance: Für Access-Dateien gilt eine begrenzte Dateigröße, die zwar mit „üblichen“ Verwaltungs-Daten nicht so schnell erreicht werden, aber je größer die Datei, desto geringer die Performance bzw. desto langsamer der Zugriff und Datentransfer. SQL-Server-Datenbanken sind frei skalierbar, Performance-Probleme sind nicht zu erwarten
5. Übergreifende Verwendung der Daten: Die Daten verfügen ggf. über die Relevanz langfristig auch mit anderen Datenbanken in Verbindung gebracht und ausgewertet werden zu können. Davon ausgehend, dass auf einem Server auch andre Daten abgelegt werden, ist eine Verknüpfung dieser Daten technische relativ einfach zu erreichen.
6. Zukunftsgerichtete Verwendung: Während sich MDB- bzw. ACCDB-Dateien als Datenbestandsführung in irgend absehbarer technisch erledigen dürften, kann davon ausgegangen werden, dass SQL-Server-Daten(banken) zukunftsfähig und für eine eventuelle Umstellung auf ein anderes Frontend geeignet sind. Auch z.B. ein browsergesteuerter Zugriff (Stichwort „Intranet“) ist schnell einzurichten.
7. Weiternutzung eines Access-Frontend bei Umstellung einer MBD bzw. ACCDB-Datendatei: Die Datenbank kann wie gewohnt weiterverwendet werden. Es sind lediglich folgende Umprogrammierungen vorzunehmen:
a. ggf. Anpassung der Feldnamen an die Richtlinien von SQL-Server
b. Umwandeln der Backend-Datei in eine SQL-Server-Datenbank – dafür gibt es Integration-Service-Tools mit denen der Vorgang automatisiert werden kann – bedenken Sie aber bitte, dass es in den allermeisten Fällen geradezu zwingend ist, in jeder Tabelle eine TimeStamp-Spalte mit aufzunehmen!
c. Anpassen eventuell geänderter Felder/Spalten in den Steuerungsformularen/Abfragen/Berichten/Codes
d. Anpassen der Abfragen in Hinsicht auf boolsche Felder Hinweis zu den boolschen Feldern: SQL-Server-Datentabellen verwenden im Gegensatz zu Access Ja/Nein-Feldern drei Zustände anstatt zwei: true, false und null das bedeutet, dass eine Abfrage (query) mitunter derart angepasst werden muss, dass es in den Kriterien heisst „…WHERE boolschesFeld = False or boolsches Feld IS NULL“
e. Anpassung des Codes in Hinsicht auf die Datenzugriffe (also die Recordsets und die OpenRecordset-Parameter, insbesondere der Parameter bzw die Konstante dbSeeChanges)
f. Erstellung einer lokalen ODBC-Verknüpfung auf allen Rechnern, auf denen die Datenbank genutzt werden soll – es sei denn die ganze Geschichte läuft über eine Citrix-Umgebung, hier gelten etwas andere Regeln: Die ODBC-Verknüpfung wird hier in der Regel im Profil angelegt.
g. Erstellung einer ODBC-Autoverknüpfung beim Start der Datenbank (Programmierung einer „Autostart“-Funktion, die den Link bzw. Connect zur Datenbank untersucht bzw. überprüft und bei Erfolg anlinkt)
h. Die Benutzer müssten in der SQL-Server Benutzertabelle geführt werden