MySQL oder Postgres, Firebird oder lieber doch SQLite? Die Wahl der richtigen Datenbank für den Desktop fällt nicht schwer, wenn man die Hintergründe kennt.

Welche Datenbank darf’s denn sein: MySQL [1] oder doch besser PostgreSQL [2]? Ist Firebird [3] das Nonplusultra oder SQLite [4]? In der Diskussion darüber tauchen nicht selten eine Fülle von Begriffen auf, die nur Datenbank-Profis verstehen, Einsteigern aber lediglich die Stirn runzeln lassen. Dabei ist die Sache ganz einfach: Für den Hausgebrauch sind wenigstens zwei Drittel der klangvollen Features ohne Bedeutung.

Warum baut man sie dann aber erst ein? Ganz einfach: Das Adressbuch oder der CD-Katalog auf dem Einzelplatzrechner stellen für eine Datenbank eher Ausnahmeanwendungen dar – typischerweise bedient sie viele Anwender, verwaltet deutlich größere Datenmengen, läuft auf einem speziellen Server und spielt eine verantwortungsvolle Schlüsselrolle in einer geschäftskritischen Applikation. Daraus resultieren besondere Anforderungen an Verfügbarkeit und Performance, an Skalierbarkeit und die Administration, an die Organisation und Integrität der Daten und nicht zuletzt an den Support.

Doch alles, was die Datenbank tut, um sich diesen Forderungen gewachsen zu zeigen, ist für den Heimanwender irrelevant. Er greift auf eine für ihre Verhältnisse lächerliche Datenportion nur gelegentlich und exklusiv zu und verkraftet wahrscheinlich selbst einen Ausfall ohne ernsthaften Schaden. Seine Bedürfnisse lasen sich mit einer kleinen Untermenge der Datenbank-Features befriedigen – und nur wenige Eigenschaften sind für ihn wirklich wichtig.

Ganz oder gar nicht

Getrost weghören kann der Alleinanwender beispielsweise bei all den komplizierten Vorkehrungen, mit denen die Datenbank die Integrität ihrer Inhalte angesichts zahlreicher paralleler Zugriffe sichert. Ob sie ihre Tabellen für jeweils einen Nutzer nur komplett oder auch zeilenweise reservieren kann, das spielt für den Einzelnutzer ebenso wenig eine Rolle wie Two-Phase-Commit, MVCC oder die Frage, ob sich durch Tablespaces oder Tabellenpartitionierung die Festplattenzugriffe gezielt auf mehrere Disks oder logische Laufwerke verteilen lassen. All das sind wichtige Fragen im Unternehmenseinsatz – sie stellen sich aber gar nicht erst, wenn es nur einen Anwender gibt.

Auch als Datenbank-Neuling sollte man dagegen wissen, dass die Datenbank hinter den Kulissen mittels so genannter Transaktionen dafür sorgt, dass eine Operation entweder nur komplett oder aber gar nicht ausgeführt wird. Dazu ein Beispiel: Stürzte etwa der Bankserver bei einer Überweisung zwischen Abbuchung und Gutschrift ab und könnte anschließend nicht erkennen, dass er diesen Arbeitsschritt erst zur Hälfte erledigt hat, wären zwei unzufriedene Kunden die Folge. Das verhindern Transaktionen nach dem ACID-Prinzip.

Geschickte Fragen

Mit einem persönlichen Adressbuch oder dem Katalog der eigenen Briefmarkensammlung hat eine Datenbank keine Performanceprobleme – es sei denn, der Anwender vergewaltigt sie mit sinnlosen oder ineffizienten Operationen. Deshalb kümmert den Einzelplatznutzer auch das Thema Performance nicht in der selben Weise wie den Profi. Weder die komplizierte Konfiguration für bestimmte Tuning-Ziele noch das Multithreading oder Load Balancing noch die Unterstützung mehrerer CPUs müssen ihn beschäftigen. Auch Skalierbarkeit wird erst bei steigender Nutzerzahl und Datenmenge relevant. Ebenfalls keine Themen für Heimanwender stellen Clusterfähigkeit, Replikationen, Point-In-Time-Recovery oder Online-Backups dar. Eine Offline-Sicherung steht allerdings auch ihm gut zu Gesicht.

Dagegen ist es nützlich zu wissen, dass die Datenbank Abfragen nie blindlings übernimmt, sondern immer in eine interne Form wandelt und dabei die einzelnen Schritte optimiert. Dabei kann der Anwender durch geschicktes Formulieren der Abfrage und durch die Anlage nützlicher Indizes helfen. Was man dabei verschenkt, lässt sich durch andere Tuning-Bemühungen in der Regel nicht mehr aufholen.

Datenbankesperanto SQL

Die kostenfreien Open-Source-Datenbanken stehen unter einer Reihe ganz verschiedener Lizenzen. Das ist für Geschäftsanwender interessant, die dadurch beispielsweise MySQL mit Herstellersupport kaufen oder ihre eigene kommerzielle PostgreSQL-Version kreieren. Für Privatanwender hat das kaum Konsequenzen. Diese Gruppe tangieren auch die verwandten Probleme der Haftung und Gewährleistung oder der Zertifizierung für bestimmte Applikationen nicht.

Schließlich spielen auch sehr spezielle Probleme im Zusammenhang mit der Abfragesprache SQL [5] für den Privatanwender eine untergeordnete Rolle. SQL wurde in mehreren Etappen standardisiert, was zu einer Reihe aufeinander folgender Standards geführt hat. Keine Datenbank – auch keine kommerzielle – unterstützt alle diese Standards vollständig. Dafür bauen fast alle zusätzliche, proprietäre Features ein. Bei der Standardkonformität ganz vorn rangiert PostgreSQL, das 150 von 164 Core-Features des jüngsten Norm SQL 2003 unterstützt. Andere gehen nicht so weit – MySQL beispielsweise hält sich an SQL 99 und kennt nur ausgewählte Elemente von SQL 2003. Aber für eine eher einfache Anwendung hat das keine ausschlaggebende Bedeutung.

Breite Sprachunterstützung

Wirklich interessant für den Hobby-Computeristen ist beispielsweise das Thema Dokumentation. Die meisten Open-Source-Datenbanken kommen mit ausführlichen und umfangreichen Manuals daher, allerdings oft nur in englischer Sprache und im Datenbankjargon. Interessiert man sich deswegen für leichter verdauliche Sekundärliteratur, dann hat eindeutig MySQL die Nase vorn. Eine Suche auf Amazon.de etwa findet 145 deutschsprachige Titel über MySQL, aber nur zwei über PostgreSQL.

Da sicher nur wenige ihre Datenbank per SQL auf der Kommandozeile befragen wollen, sind die Sprachanbindungen von Interesse, die die Integration in eigene Applikationen mit GUI erlauben. Allerdings nehmen sich in diesem Punkt PostgreSQL und MySQL nicht viel: Beide können mit einer langen Liste von Skript- und Programmier-Hochsprachen zur Unterstützung aufwarten. Dazu tragen nicht zuletzt die JDBC– und ODBC-Schnittstellen bei. PostgreSQL verfügt darüber hinaus über eine eigene eingebaute Sprache namens PGSQL, die sich an Oracles PSQL anlehnt.

Administrieren muss auch der Heimanwender seine Datenbank. Die meisten Open-Source-Datenbanken bringen dafür neben Kommandozeilenwerkzeugen (CLI) auch grafische Tools mit. MySQL etwa verfügt mit dem MySQL Administrator [6] über ein Verwaltungs- und Monitoringwerkzeug, daneben über ein Abfragetool (MySQL Query Browser), ein Migration Toolkit und die Beta-Version einer MySQL Workbench. PostgreSQL kann mit PgAdmin [7] oder PgAccess [8] (Abbildung 1) für die Administration und einem Web-Frontend für denselben Zweck aufwarten (PHPPgAdmin). Firebird stützt sich auf Third-Party-Tools wie FlameRobin [9] (Abbildung 2), das es für Linux, Mac OS und Windows gibt. Daneben existieren plattformübergreifende Werkzeuge, die alle genannten Datenbanken bedienen. Kurz: Signifikante Unterschiede gibt es auf diesem Gebiet nicht.

Abbildung 1: Ein Blick auf die Tabellen einer Beispieldatenbank mit PgAccess, einem der grafischen Administrationswerkzeuge für PostgreSQL.

Abbildung 2: In FlameRobin, einem Admin-Tool für Firebird, das unter verschiedenen Betriebssystemen läuft, lassensich auch neue Datenbanken kreieren.

Für alle, die mit diesem Hintergrundwissen auf die Suche nach einer passenden Datenbank für eigene Experimente gehen wollen, haben wir im folgenden Kurzporträts einiger wichtiger Kandidaten zusammengestellt.

MySQL

MySQL zählt sicher zu den bekanntesten Open-Source-Datenbanken, was nicht zuletzt das Akronym LAMP widerspiegelt: Der Name des wohl verbreitetsten Softwarestacks für Webserver lautet ausgeschrieben Linux, Apache, MySQL und PHP. Daneben ist MySQL Bestandteil zahlreicher weiterer Open-Source-Produkte – zum Beispiel der Content-Management-Systeme Typo3 oder Drupal – und kommt auch bei namhaften kommerziellen Nutzern zum Einsatz, darunter Yahoo und die NASA.

Die Datenbank existiert als Produkt der schwedischen Firma MySQL AB seit 1995 und wird sowohl unter einer kommerziellen Lizenz wie der GPL angeboten. Lange ging ihr der Ruf voraus, zwar recht schnell zu sein, dafür aber auf Standards und fortgeschrittene Features zu verzichten. Diese Kritik ist heute nur noch bedingt berechtigt, denn die letzten Versionen, namentlich das Release 5.0, rüsteten zahlreiche lange vermisste Eigenschaften nach: etwa Stored Procedures, Views und Trigger oder Two-Phase-Commits.

Allerdings – das ist die hervorstechende Eigenheit von MySQL – kann nicht jede Tabelle alles. Insgesamt 11 so genannte Datenbank-Engines unterstützen jeweils einen Tabellentyp mit besonderen Eigenschaften. Kein Typ beherrscht sämtliche Features: So kennt nur der Typ InnoDB Foreign Keys oder Tablespaces, nur InnoDB und BerkeleyDB beherrschen Transaktionen. Andererseits ist Volltext-Indizierung nur mit MyISAM-Tabellen möglich und nur der Typ NDB taugt für Clustering oder Load Balancing.

Kürzlich erregte MySQL Aufsehen mit einem pikanten Detail: Die Entwicklerfirmen InnoBase und Sleepycat, die für zwei der wichtigsten Tabellentypen – InnoDB und BerkeleyDB – verantwortlich zeichnen, wurden 2005 vom Konkurrenten Oracle gekauft. Was das für die Zukunft von MySQL bedeutet, ist derzeit Anlass für Spekulationen.

PostgreSQL

Der Name der weitbekannten, freien Datenbank geht auf ein Forschungsvorhaben der Universität Berkeley im Jahre 1986 zurück, das an das Datenbankprojekt Ingres anschloss und deshalb Postgres getauft wurde. Nach Auslaufen der Forschungsarbeiten 1995 entließen die Wissenschaftler PostgreSQL unter der BSD-Lizenz in die Öffentlichkeit. Da diese Lizenz im Unterschied zur GPL das Schließen des Codes von abgeleiteten Entwicklungen erlaubt, existieren heute etliche Closed-Source-Verwandte von PostgreSQL, wie etwa EnterpriseDB oder Bizgres. Aber auch für PostgreSQL selbst gibt es kommerziellen Support (in Deutschland über die Firma Credativ). Unter den PostgreSQL-Nutzern finden sich wie bei MySQL zahlreiche bekannte Namen, etwa BASF, Fujitsu oder die Wochenzeitung “Die Zeit”.

PostgreSQL bietet hervorragende SQL-Konformität und eine sehr große Funktionsvielfalt. So wartet es beispielsweise mit einer Fülle besonderer Datentypen auf, darunter solchen für geografischen Koordinaten, Boolsche Werte oder Netzwerkadressen. Auch an Index-Typen hat Postgres mehr zu bieten als alle Open-Source-Konkurrenten. Dafür fehlt ihm etwa im Vergleich zu MySQL die Möglichkeit, Hochverfügbarkeitscluster zu bilden, es gibt kein Load Balancing und kein Multi-Threading.

PostgreSQL wird wie auch MySQL von einer sehr aktiven Community getragen, zu den kommerziellen Unterstützern zählt seit Ende letzten Jahres die Firma Sun, die PostgreSQL in Solaris integrieren und auch Support anbieten will.

Firebird

Firebird gehört zu den freien Datenbanken mit kommerzieller Vorgeschichte. In diesem Fall geht der Sprössling auf eine Affäre der Firma Borland mit der Open-Source-Community zurück, der im Jahr 2000 die sieche Datenbank Interbase 6.0 in der Hoffnung auf Wiederbelebung übergeben wurde. Diese Rechnung ging nicht auf, den Interbase-Code schloss Borland später wieder. Aus der kurzen Liaison war aber bereits Nachwuchs in Gestalt von Firebird hervorgegangen, das seinerseits aktive Anhänger in der Open-Source-Welt fand und sich bis heute weiterentwickelt. Momentan ist es in der Dritten Welt (namentlich in Brasilien) und Osteuropa verbreiteter als hierzulande oder in den USA.

Die Anwender finden in Firebird eine solide und zuverlässige SQL-Datenbank, der allerdings einige der fortgeschritteneren Features fehlen. So gibt es weder Cluster noch Load Balancing, keine Replikation, keine Volltextsuche, keine Tablespaces, keine Schemas, keine räumlichen Datentypen, und so weiter. Multi-Threading und Multi-Prozessor-Support kann man nur alternativ, aber nicht gleichzeitig haben.

Andererseits punktet Firebird mit einfacher Installation und guten Cross-Plattform-Fähigkeiten. In diesem Punkt stellt es beispielsweise auch PostgreSQL in den Schatten, das unter Windows lange ein Schattendasein fristete.

SQLite

SQLite nimmt in unserer Datenbankauswahl eine Sonderstellung ein: Im Unterschied zu den bereits vorgestellten Vertretern arbeitet es nicht nach dem Client-Server-Prinzip und eignet sich daher besonders dafür, in andere Applikationen eingebettet zu werden. Alle Tabellen landen in einem einzigen File, was zwar die maximale Größe der Datenbank auf den Umfang des größtmöglichen Files beschränkt, andererseits aber beispielsweise das Backup sehr vereinfacht. Von SQL beherrscht SQLite nur den Grundwortschatz, der allerdings für sehr viele Anwendungen vollkommen ausreicht. Als Lohn der Selbstbeschränkung wartet es dafür mit einfachster Installation, sehr guten Integrationsfähigkeiten und einer herausragenden Performance auf.