MS Access gilt in der Entwicklerwelt als Schmuddelkind: zu langsam für echte Last, zu fragil für produktive Systeme, zu proprietär für moderne Architekturen. Meistens zurecht. Aber manchmal ist eine MS-Access-Datenbank einfach da – gewachsen über Jahre, gefüllt mit Daten, die das Unternehmen täglich braucht. Und dann bekommt man eine Anfrage, die so klingt: "Wir haben eine PHP-Anwendung und eine Access-Datenbank. Kannst du die verbinden?"

Die Ausgangssituation

Der Kunde betrieb eine interne PHP-Webanwendung und daneben eine gewachsene MS-Access-Datenbank, die von einem kleinen Team täglich für operative Prozesse genutzt wurde. Die Daten in Access waren aktuell, gepflegt und geschäftskritisch. Die PHP-Anwendung sollte auf genau diese Daten zugreifen – lesend und schreibend.

Ein sofortiger Datenbankwechsel war keine Option. Die Access-Datenbank war tief in die Arbeitsabläufe eingebettet, und eine Migration hätte Monate gedauert. Dazu kam: Als kleiner Betrieb gab es kein Budget für eine umfangreiche Modernisierung am Stück – sehr wohl aber für eine Lösung, die die Weichen für eine spätere Migration richtig stellt. Gefragt war also eine Lösung, die jetzt funktioniert und den Weg für eine spätere Migration offenhält.

Die technische Lösung: Doctrine DBAL mit MS-Access-Treiber

Die PHP-Anwendung nutzte bereits Doctrine DBAL für den Datenbankzugriff – eine Abstraktion, die verschiedene Datenbankplattformen hinter einer einheitlichen API verbirgt. Für MS Access gibt es keinen offiziellen Doctrine-Treiber, aber mit doctrine-dbal-msaccess existiert eine Community-Lösung, die genau diese Lücke schließt.

Die Bibliothek nutzt intern ODBC, um auf die .mdb- bzw. .accdb-Datei zuzugreifen, und stellt darüber eine Doctrine-kompatible Verbindung bereit. Die Konfiguration ist überschaubar: 

$connectionParams = [
    'driver' => 'msaccess',
    'host'   => '/pfad/zur/datenbank.accdb',
];

$connection = DriverManager::getConnection($connectionParams);

Ab diesem Punkt verhält sich die Verbindung wie jede andere Doctrine-Verbindung: QueryBuilder, executeQuery, fetchAllAssociative – alles funktioniert wie gewohnt. Die Anwendung musste an keiner Stelle wissen, dass sie gegen Access spricht.

Was dabei zu beachten ist

MS Access ist kein vollständiger SQL-Server. Einige SQL-Konstrukte werden nicht oder anders unterstützt. Auch Transaktionen haben Grenzen – Access ist keine transaktionale Datenbank im klassischen Sinne. Für die konkreten Anforderungen des Kunden war das kein Problem, hätte bei höherer Schreiblast aber zu einem werden können.

Und schließlich: die Datei selbst. Eine .accdb-Datei ist keine Netzwerkdatenbank. Sie liegt auf einem Server-Laufwerk und wird über Dateizugriff gesperrt, sobald jemand schreibt. Für den Einsatz als Einzelplatz-Lösung mit gelegentlichem PHP-Zugriff war das vertretbar. Für mehrere gleichzeitige Schreibzugriffe wäre es das nicht.

Warum das trotzdem die richtige Entscheidung war

Technisch betrachtet ist MS Access als Datenbankbasis für eine Webanwendung nicht ideal – das war mir und dem Kunden von Anfang an klar. Aber die Entscheidung war keine technische, sondern eine geschäftliche: Die Access-Datenbank enthielt Daten, die das Team täglich brauchte, und eine sofortige Migration wäre mit erheblichem Aufwand, Risiko und Betriebsunterbrechung verbunden gewesen.

Die beste Lösung ist nicht immer die technisch sauberste – sondern die, die das Unternehmen heute weiterlaufen lässt und morgen eine bessere Option offenhält.

Mittelfristig wird die Access-Datenbank durch ein geeigneteres System ersetzt. Und genau dafür ist die gewählte Architektur vorbereitet: Weil die PHP-Anwendung über Doctrine DBAL abstrahiert gegen die Datenbank spricht, reicht ein Konfigurationswechsel, um auf MySQL, PostgreSQL oder einen anderen Treiber umzustellen. Die Anwendungslogik bleibt unangetastet.

Fazit

Diese Fallstudie ist kein Plädoyer für MS Access in modernen Systemen. Es ist ein Beispiel dafür, dass Pragmatismus und saubere Architektur kein Widerspruch sein müssen. Die DBAL-Abstraktion hat genau das geleistet, wofür sie gedacht ist: Datenbankdetails kapseln, Migrationen vereinfachen, technische Schulden kontrolliert aufnehmen statt zu ignorieren. Wer heute die richtige Abstraktion wählt, hat morgen mehr Spielraum.