Datendiener

In der Rangliste der mit beinahe religiösem Eifer diskutierten Software-Kategorien haben Datenbanken sicher einen Platz unter den ersten drei inne, gleich nach Betriebssystemen und in stetiger Konkurrenz zu Programmiersprachen. Dabei ist gerade die Diskussion um Datenbanken geprägt von großer Begriffsverwirrung und von Äpfel-mit-Birnen-Vergleichen. Schon der Begriff ‘Datenbank’ kann je nach Kontext für recht unterschiedliche Dinge stehen: für ein Stück Software, das Daten beliebigen Umfangs strukturiert und verwaltet, für ein Programm, mit dem man auf eine solche Datensammlung zugreifen kann, manchmal auch für einen Bestand an Informationen selbst.

Schuld an diesen Unklarheiten sind nicht zuletzt die Softwarehersteller, die mit ihren Produkten die Grenzen zwischen diesen eigentlich sauber zu trennenden Begriffen verschwimmen lassen. Programme wie Microsoft Access, Corel Paradox oder Filemaker enthalten sowohl einen Teil zur Datenverwaltung als auch eine Bedienoberfläche, mit der man auf diese Daten komfortabel zugreifen kann. Auf den ersten Blick scheinen diese Programme ‘aus einem Guss’ zu sein. Dabei kann man mit ihnen einerseits durchaus Datenbestände verwalten, die extern in einem völlig anderen Format gespeichert sind. Andererseits ist es auch möglich, auf die in ihnen verwalteten Daten mit anderen Programmen zuzugreifen.

Eine Datenbankanwendung besteht also immer aus mindestens zwei logisch voneinander zu trennenden Schichten: Einem Front-End, das die Bedienoberfläche bildet, und einem Back-End, das sich um die eigentliche Datenhaltung kümmert. Bei gängigen Business-Anwendungen liegt dazwischen noch eine Schicht, die die Programmlogik implementiert.

In diesem Artikel geht es um reine Datenbankserver, also die Back-Ends zur Datenhaltung in dieser Architektur. Wir haben uns vier Vertreter dieser Kategorie genauer angesehen, die alle frei und im Quelltext verfügbar sind: MySQL vom gleichnamigen schwedischen Softwarehaus, die aus einem Forschungsprojekt entstandene, lupenreine Open-Source-Datenbank PostgreSQL, Firebird, ein freier Abkömmling von Borlands InterBase, und die SAP DB, die von der für ihre ERP-Anwendungen bekannten Walldorfer SAP AG stammt. Alle vier treten in einem Markt an, in dem sich ansonsten die ganz Großen der Software-Branche wie Microsoft, Oracle oder IBM tummeln, und bilden eine zumindest bedenkenswerte Alternative zu deren horrenden Preisen und teilweise abenteuerlichen Lizenzmodellen.

All diese Datenbankserver verwalten die ihnen anvertrauten Informationen in untereinander verknüpften Tabellen, so genannten Relationen, woher auch die Bezeichnung ‘relationale Datenbanken’ kommt. Zur Definition der Datenstrukturen, zum Pflegen und zum Abfragen der Daten dient durchgängig eine Sprache namens SQL (Structured Query Language), die in den 1970er Jahren bei IBM entwickelt wurde und zuerst in einem Datenbanksystem namens System/R zum Einsatz kam. Mittlerweile gibt es die Definition dieser Sprache in zwei ANSI/ISO-Standards namens SQL92 (ISO/IEC 9075) und SQL99 (ISO/IEC 9075:1999), deren Namen auf ihr jeweiliges Erscheinungsdatum hindeuten. Eine im Markt relevante Bedeutung hat bis heute eigentlich nur SQL92; die Version aus dem Jahre 1999 konnte sich noch nicht auf breiter Front durchsetzen. Inwieweit eine Datenbank diese Standards unterstützt, ist ein nicht unerhebliches Kriterium bei der Auswahl eines Produkts. Trotz aller Versprechen der Hersteller kocht nämlich im Detail jeder sein eigenes Süppchen, und das Auswechseln des Datenbankservers in einer bestehenden Anwendung ist immer mit einem gewissen Aufwand verbunden. Einen bemerkenswerten Weg geht hier die SAP DB. Sie kennt insgesamt vier SQL-Dialekte, zwischen denen man als Entwickler wählen kann: Neben der SAP-eigenen INTERNAL genannten Betriebsart stehen ein strikt SQL92-konformer Modus und die Sprachversionen von IBMs DB2 in Version 4 sowie von Oracle7 zur Verfügung.

Wenn ein Programmierer für seine Anwendung einen Dienst in Anspruch nehmen möchte, braucht er dazu eine Möglichkeit, Funktionen oder Prozeduren aufzurufen. Jede Datenbank bringt daher ein eigenes API (Application Programming Interface) mit, über das Programmierer Funktionen des Servers aufrufen können. Entscheidend bei der Auswahl einer Datenbank für ein bestimmtes Projekt ist die Frage, mit welchen Programmiersprachen ein Entwickler diese Schnittstellen ansprechen kann. Alle vier Kandidaten bringen Bibliotheken und Header-Dateien für die Anbindung von C/C++-Programmen mit.

Neben diesen produktspezifischen, so genannten Call Level Interfaces (CLI), haben sich einige universelle Schnittstellen etabliert, die die Details einer Datenbankimplementierung vor dem Programmierer verbergen sollen und so dafür sorgen, dass sich beim Umstieg auf eine andere Datenbank der Portierungsaufwand im Rahmen hält. Um eine solche Schnittstelle verfügbar zu machen, muss der Datenbankhersteller Treiber für sein Produkt bereitstellen, der dann auf den Client-Maschinen installiert wird und die universellen Aufrufe in produktspezifische umwandelt, bevor er sie an den Server weiterreicht. Die prominenteste Schnittstellendefinition dieser Art ist sicherlich ODBC (Open DataBase Connectivity), einst von Microsoft entwickelt und mittlerweile auch auf Nicht-Windows-Betriebssystemen zuhause. Möglichkeiten zum Aufruf dieser Schnittstelle bieten eigentlich alle Programmiersprachen, außerdem wird sie gerne von universellen Datenbank-Front-Ends benutzt. Java-Programmierer schwören statt dessen auf eine Schnittstelle namens JDBC, und für die Anbindung an Perl ist ein so genanntes DBI-Modul unerlässlich. Die in der Tabelle auf Seite 147 aufgeführten Schnittstellen bilden sicher keine vollständige Liste: Gerade für MySQL und PostgreSQL gibt es in der Open-Source-Szene Anbindungen an die exotischsten Entwicklerwerkzeuge, die allerdings nicht immer offiziell unterstützt und teilweise noch im Experimentierstadium sind.

Alle vier Kandidaten für diesen Bericht laufen unter Linux und diversen anderen Unix-Versionen sowie unter Windows. Wir haben uns das jeweils neueste zur Verfügung stehende RPM-Paket aus dem Internet besorgt und auf einem unter Red Hat Linux 7.3 laufenden PC (P4 1,7 GHz, 256 MByte Hauptspeicher) installiert.

Auf Benchmarks haben wir bewusst verzichtet: Jeder Versuch, die Datenbanken unter einen Hut zu bringen und dabei jeder gerecht zu werden, ist zum Scheitern verurteilt. Die individuelle Anpassung von Tests an die nativen Bibliotheken, die dafür nötig wäre, ist zu aufwendig. Der Rückgriff auf eine gemeinsame Schnittstelle, etwa ODBC, würde letztlich vor allem Ergebnisse darüber liefern, wie gut die Implementierung dieser Zwischenschicht ausgefallen ist. Wer sich die eine oder andere Datenbank ausgeguckt hat, sollte in jedem Fall eigene Experimente anstellen, ob sie seinen Ansprüchen genügt. Ein solcher Versuch ist allemal aussagekräftiger als jeder Benchmark, den Sie in einer Zeitschrift lesen.

">

(hos)