Wie die wirtschaftlichste Datenbank finden, wenn keiner der Probanden einen Preis hat? Jenseits von Glaubensbekenntnissen oder Ratlosigkeit gibt es handfeste Kriterien für die Wahl der geeignetsten Datenablage. An ihnen messen sich in diesem Vergleich acht kostenlose Kandidaten.

Was nichts kostet, ist nichts wert. Wofür auch immer das stimmen mag, für Software ist es schon lange nicht mehr wahr. Im Gegenteil: “Viel Fleiß, kein Preis” dürfte als Motto für zahlreiche Open-Source-Projekte gelten, die unentgeltlich hochwertige und konkurrenzfähige Programme produzieren. Vom einfachen Tool bis zur komplexen Datenbank, um die es hier gehen soll.

Auch zahlreiche Schnupperversionen kommerzieller Datenspeicher werben mit dem Wegfall der Lizenzkosten und versuchen damit potenzielle Kunden zu ködern. In beiden Fällen minimiert sich für die Anwender das Investitionsrisiko. Im Gegenzug spitzt sich alles auf die Frage zu: Was soll man sich nun schenken lassen? Im Angebot sind unter anderem: MySQL, Max DB, PostgreSQL, Firebird, Ingres 2006, Oracle XE, DB2 Express-C oder Sybase ASE Express Edition. Alle sind kostenlos zu haben. Aber welches Produkt ist für welchen Zweck das beste?

Der Zweck diktiert die Mittel

Das mit weitem Abstand wichtigste Kriterium ist natürlich der Einsatzzweck. Eine Datenbank wird selten solo betrieben, sondern werkelt meist hinter den Kulissen einer Applikation. Diese Anwendung baut wahrscheinlich auf bestimmte Eigenschaften und Fähigkeiten ihrer Datenablage und unterstützt deshalb nur bestimmte Produkte, was die Auswahl drastisch einschränkt.

Der Zweck hat aber noch weitere Implikationen, denn auch die Grenzwerte für Performance, Verfügbarkeit oder Sicherheit lassen sich nur in Relation zu ihm definieren. Deshalb empfiehlt es sich, im ersten Schritt so konkret wie möglich die Anforderungen zu bestimmen, die später mit den Feature-Listen in Übereinstimmung zu bringen sind.

Pauschalurteile unmöglich

Ein vollständiger Vergleich aller Fähigkeiten verschiedener Datenbanken ist schwer zu leisten. Das liegt nicht nur an der Komplexität der Produkte, ihrer nicht immer deckungsgleichen Terminologie oder der unterschiedlichen Architektur, sondern mehr noch daran, dass sich die Implementierung ein und desselben Features von Fall zu Fall stark unterscheidet.

So mögen beispielsweise zwei Datenbanken Sperren auf Zeilenebene beherrschen, eine Dritte verwendet stattdessen Multi-Version Conrurrency Control (MVCC) und organisiert konkurrierende Zugriffe mit Hilfe mehrerer Versionen eines Objekts. Das mag günstiger sein, wenn hauptsächlich gelesen wird, in anderen Fällen aber einen größeren Overhead erzeugen – pauschal ist die bessere Variante kaum zu ermitteln.

Selbst zwischen den beiden Konkurrenten, die auf Row Level Locks setzen, kann es große Unterschiede geben. Der eine beansprucht wenig Ressourcen, etwa weil die Datenbank im Bedarfsfall per Lock-Eskalation große Mengen einzelner Zeilen-Locks wieder zu Sperren auf Tabellenebene verdichtet (etwa DB2) oder Locks automatisch konvertiert (etwa Oracle) und so die Kosten minimiert. Dem anderen fehlt dagegen solche Intelligenz und im Ergebnis steigt bei ihm der Aufwand womöglich linear mit der Anzahl der Datensätze.

Letzteres ist natürlich ein Nachteil, wie stark der allerdings ins Gewicht fällt, entscheidet wiederum der Zweck: Eine Ablage für Webseiten-Elemente ohne konkurrierende Zugriffe wird sich an den teuren Locks nicht stören, eine viel frequentierte, interaktiv benutzte OLTP-Anwendung dagegen schon.

Auf den zweiten Blick

Ein vergleichbares Bild ergibt sich bei vielen Features: Hinter dem gleichen Namen verbergen sich nicht selten verschiedene Welten. So verfügt jede Datenbank über einen so genannten Query Optimizer, der ermitteln soll, wie sie am effektivsten die angefragten Daten bereitstellen kann. Dafür entwickelt der Optimierer eine interne Strategie, die beispielsweise festlegt, ob und welche Indizes zu Rate zu ziehen sind. Allerdings kommt es dabei vor, dass einfach gestrickte Optimierer selbst zum Engpass werden, weil sie mehr Zeit für die Suche nach Wegen verplempern als für die ganze Strecke schlimmstenfalls gebraucht worden wäre. Andere Produkte wiederum verfügen über ausgefeilte Optimierungsmethoden, die tatsächlich Rechenzeit in beachtlichen Größenordnungen einsparen.

Ein weiteres Beispiel sind Cluster. In einem Fall mögen sie aus höchstens einer Hand voll Knoten bestehen und dazu noch empfindlich Performance kosten, im anderen Fall können sie – etwa bei DB2 – leicht hunderte Knoten ohne Leistungsabfall integrieren. Eine erfolgreiche Tauglichkeitsprüfung erfordert also, nicht reflexartig einen Haken auf der Checkliste zu setzen, sobald man auf ein Buzzword stößt, sondern genau zu ermitteln, was tatsächlich gemeint ist.

Das allerdings ist nicht immer leicht, denn allzu gern deckt der Hersteller über eine faktische Blöße das Mäntelchen des Marketings. Trotzdem bietet [1] einen sehr umfangreichen, detaillierten und unparteiischen Überblick über die Features etlicher freier Datenbanken.

Betriebserlaubnis

Von ähnlicher Trennschärfe wie der Zweck sind die Lizenzbestimmungen: So gibt es bereits bei den Lizenzen für nicht kommerzielle Datenbanken eine bunte Vielfalt – so gut wie jedes Produkt benutzt eine eigene Spielart. Das hat zum Teil gravierende Konsequenzen: Beispielsweise sind abgeleitete Closed-Source-Produkte nach der BSD-Lizenz gestattet und etliche Postgres-Nachfahren machen Gebrauch davon – die GPL dagegen würde das verbieten.

Obwohl es keine Preisunterschiede mehr gibt, fallen beim Entwickeln eines Programms samt Datenbank, das als freie Software weiterleben soll, von vornherein die proprietären Light-Versionen der Datenbank weg, weil sie stets ohne Quelltext und nur unter unfreien Lizenzen weitergegeben werden. Manche Hersteller – etwa Oracle – warnen explizit vor möglichen Konflikten, die sich im Open-Source-Umfeld mit ihrer Datenbank ergeben können. Bei freien Produkten entfallen diese Probleme.

Das ist aber beileibe nicht der einzige Vorteil. So ist ein weiterer Nachteil der kommerziellen Produkte eng mit der Lizenzfrage verbunden: Weil Closed-Source-Software in der Regel als Binärversion daherkommt, steht sie nur für einzelne Betriebssysteme und Releases in wenigen Paketformaten bereit. In der Regel erwartet der Hersteller eine Enterprise-Distribution und gibt die Kernel- und Glibc-Version vor.

Wer auf seinem Server also beispielsweise ein leicht exotisches Gentoo fährt, wird zwar MySQL im Handumdrehen aufspielen, darf aber bei keiner proprietären Kostenlos-Variante mit einer problemlosen Installation rechnen. Die Voraussetzungen für Hard- und Software bilden aus diesem Grund nach Zweck und Lizenz ein drittes wesentliches Auswahlkriterium.

Mit Blick auf die kommerziellen Light-Versionen ist noch zu bedenken, dass sie gar keinen so bedeutenden Feature-Vorsprung ins Feld führen können wie ihre großen Geschwister. Letztere sind den Open-Source-Produkten zwar oft im Funktionsumfang deutlich voraus, beispielsweise kennt keine einzige freie Datenbank die auf dem Ergebnis von Abfragen beruhenden Materialized Views. Aber den speziellen Einsteigerangeboten fehlen häufig gerade viele der Highend-Funktionen, etwa die Hochverfügbarkeits-Mechanismen.

Dadurch verkehrt sich das Bild partiell ins Gegenteil: Bei der Community-Edition von DB2 etwa ist das Replikations-Feature nur teilweise verfügbar und die Spatial-Option ist ganz ausgespart. Manche freie Datenbank, beispielsweise Ingres oder PostgreSQL, bietet diese Möglichkeiten aber komplett und ohne Abstriche an.

Dennoch gibt es natürlich sinnvolle Anwendungen für die kleinsten Varianten der Kommerzprodukte. Wer im Umgang mit den ausgewachsenen Verwandten bereits über Know-how verfügt oder mit ihnen gerade solche Erfahrungen sammeln möchte, der findet auf diesem Weg einen risikolosen Einstieg. Auch für Tests und zur Evaluierung eignen sie sich hervorragend – solange der Anwender keine Features benötigt, die ihm diese Ausgabe bewusst vorenthält.

Spielwiese mit Wachstumspfad

In aller Regel kann man auch für die Leichtgewichte die sehr gute, für die Profi-Verwandten erstellte Dokumentation mitbenutzen, von deren Qualität manche freie Doku weit entfernt ist. Oft haben die kommerziellen Datenbanken eine längere Entwicklung hinter sich und mussten sich außerdem in vielfältigeren und größeren Umgebungen bewähren als die freien Kontrahenten. Oracle beispielsweise existiert seit 1977, DB2, wenn man das Vorläufersystem R mitrechet, seit 1975 – außer Ingres ist kein freier Konkurrent auch nur annähernd so lange im Geschäft.

Zudem öffnen sie eine Migrationsperspektive, die bei wachsenden Anforderungen wichtig werden kann: Ist nämlich später ein spezielles Feature erforderlich, das es nur für Geld gibt, ist der Umstieg von der Light- auf die Vollversion ein Kinderspiel. Eine Migration von einer freien Datenbank zu einem kommerziellen Produkt wäre im Unterschied dazu sehr viel aufwändiger.

Abbildung 1: MySQL-Admin versammelt die meisten Verwaltungsaufgaben unter einer grafischen Oberfläche, auf der Eingangsseite werden Statusinformationen präsentiert.

MySQL

MySQL [2] ist sicherlich die bekannteste Open-Source-Datenbank überhaupt, die Rede ist von zehn Millionen Installationen weltweit. Ihre Geschichte reicht bis in das Jahr 1994 zurück. In der Zwischenzeit avancierte sie zum festen Bestandteil zahlreicher Linux-Distributionen. Seit dem Jahr 2000 wird das Produkt der schwedischen Firma MySQL AB unter einer kommerziellen Lizenz sowie unter der GPL angeboten.

Lange ging MySQL der Ruf voraus, zwar recht schnell zu sein, dafür aber auf Standards und fortgeschrittene Features zu verzichten. Eine Zeit lang war dieser Ruf nicht unberechtigt, denn die Datenbank unterstützte nur den Entry-Level des Standards SQL 92 und kannte weder Transkationen noch Views oder Subqueries. Entsprechend kam sie auch vor allem als Backend für eher einfache Webanwendungen mit PHP oder Perl in Frage, bei denen der Kostenaspekt im Vordergrund steht.

Heute allerdings ist diese Kritik nur noch bedingt berechtigt, denn die letzten Versionen, namentlich die Release 5.0, haben zahlreiche lange vermisste Eigenschaften nachgerüstet. Inzwischen versucht sich die Datenbank zudem ausdrücklich für Geschäftsanwendungen interessant zu machen und bietet dafür etwa Stored Procedures, Views und Trigger oder Two-Phase-Commits für verteilte Datenbanken. Transaktionen gibt es sogar schon länger.

Alles Gute nie beisammen

Jedoch – das ist eine hervorstechende Eigenheit von MySQL – kann nicht jede Tabelle alles. Etliche so genannte Storage Engines [3] 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, Volltext-Indizierung ist nur mit »MyISAM«-Tabellen möglich und nur der Typ »NDB« taugt für Clustering oder Load Balancing. Das ist gewollt und soll dort Performance-Vorteile erschließen, wo die Anwendung gezielt auf bestimmte Leistung fressende Eigenschaften verzichten kann.

Wer also unter bestimmten Umständen keine Transaktionssicherheit braucht, kann den Verzicht darauf im besten Fall in einen Geschwindigkeitsvorteil ummünzen. Im schlechtesten Fall verursacht das Konzept der unterschiedlichen Storage Engines aber zusätzliche Administrationsprobleme, weil es den Admin – entgegen der reinen Lehre – zum Nachdenken über Interna zwingt, die eine Datenbank eigentlich vor ihrem Anwender verbergen sollte.

Im letzten Jahr erregte MySQL Aufsehen mit einem pikanten Detail: Die Entwicklerfirmen Inno Base und Sleepycat, die für die beiden wichtigsten, weil einzig transkationsfähigen Tabellentypen – Inno DB und Berkeley DB – verantwortlich zeichnen, wurden vom Konkurrenten Oracle gekauft. Mit zwei neuen Engines, darunter einer Eigenentwicklung unter dem Namen Falcon, geleitet vom ehemaligen Firebird-Entwickler Jim Starkey, versucht MySQL nun Unabhängigkeit zurückzugewinnen [4].

Max DB

Das zweite MySQL-Produkt, die heutige Max DB [5], blickt auf ein sehr bewegtes Leben zurück: Als Forschungsprojekt der TU Berlin geboren und VDN, später RDS getauft, hat Nixdorf die Datenbank 1981 kommerzialisiert. Fortan hieß sie Reflex beziehungsweise DDB/4. 1992 gelangte sie in den Besitz der Software AG, die sie erst Eintire SQL Server und später Adabas D nannte.

Dieses Produkt übernahm 1997 schließlich SAP und änderte seinen Namen in SAP DB. Drei Jahre später entließ SAP seine Datenbank unter die GPL und ging wieder drei Jahre später eine Kooperation mit MySQL ein, der die Max DB ihren heutigen Namen verdankt.

Während der Vertrieb in den Händen der Schweden liegt, leistet SAP nach wie vor den Hauptteil der Entwicklungsarbeit und zertifiziert das Ergebnis für seine ERP-Systeme. Durch parallele Abfragebearbeitung, Point-in-Time-Recovery, Replikation, Clustering oder Online-Backups besonders für Geschäftsanwendungen geeignet, verfügt die Datenbank derzeit über etwa 6000 Anwender, darunter prominente Namen wie Intel, Toyota, die Deutsche Post oder Daimler-Chrysler.

PostgreSQL

Im Jahr 1986 schloss die Universität Berkeley in Kalifornien ihr Datenbank-Forschungsprojekt Ingres ab (siehe unten) und startete den Nachfolger, den sie in Anspielung darauf Postgres taufte. Die Forschungsarbeiten liefen 1995 mit der Postgres-Version 4.2 aus, die bereits so viele Anwender gefunden hatte, dass der Supportaufwand den Forschern über den Kopf zu wachsen drohte.

Später gab es aber einen erweiterten und auch schnelleren Open-Source-Ableger unter dem Namen Postgres 95, der jedoch 1996 umgetauft wurde, nachdem er dem Geburtsjahr im Namen entwachsen war. Seitdem heißt die Datenbank PostgreSQL [6], was auf den zur ursprünglichen Postgres-Engine hinzugefügten SQL-Interpreter hinweisen soll.

Die Versionsnummer setzte das Projekt bei der letzten Namensänderung auf 6.0 zurück. Im vergangenen Jahr erreichte die Datenbank Version 8.1. Heute steht sie unter der BSD-Lizenz. Da diese im Unterschied zur GPL das Schließen des Code von abgeleiteten Entwicklungen erlaubt, gibt es etliche Closed-Source-Verwandte von PostgreSQL wie Enterprise DB oder Bizgres. Auch für PostgreSQL selbst ist kommerzieller Support verfügbar, in Deutschland unter anderem durch die Firma Credativ [7].

Heute gehört PostgreSQL zusammen mit MySQL zu den bekanntesten und verbreitetsten Open-Source-Datenbanken. Unter ihren Nutzern finden sich klangvolle Namen, etwa BASF, Fujitsu oder die Wochenzeitung “Die Zeit”.

PostgreSQL bietet hervorragende SQL-Konformität und eine sehr große Funktionsvielfalt. Es wartet beispielsweise mit vielen besonderen Datentypen auf, darunter solchen für geografische Koordinaten, boolesche Werte oder Netzwerkadressen. Auch an speziellen Indextypen hat PostgreSQL eine größere Auswahl zu bieten als jede andere Open-Source-DB. Dafür fehlt – etwa im Vergleich zu MySQL – eine eigene Lösung für Hochverfügbarkeits-Cluster, es gibt kein Load Balancing und kein Multi-Threading.

PostgreSQL wird – ebenso wie MySQL – von einer sehr aktiven Community getragen. Zu den prominenten kommerziellen Unterstützern zählt seit Ende 2005 auch die Firma Sun.

Abbildung 2: Eine Tabellenübersicht, und zwar präsentiert von einem der am weitesten verbreiteten GUI-Tools für PostgreSQL, Pg Access. Die meisten Verwaltungsarbeiten erledigt der Administrator an dieser zentralen Stelle mit grafischer Unterstützung.

Firebird

Firebird [7] gehört zu den freien Datenbanken mit kommerzieller Vergangenheit: Im Jahr 2000 übergab die Firma Borland ihre Datenbank Interbase 6.0, die nach anderthalb Jahrzehnten wechselvoller Geschichte zur kostenlosen Dreingabe zu JBuilder oder Delphi verkommen war, der Open-Source-Gemeinde. Die Hoffnung erfüllte sich aber nicht, damit an glorreiche Zeiten anzuknüpfen, in denen Interbase zu den technischen Vorreitern zählte, etwa bei der Einführung von Blobs Ende der 80er Jahre, und zu Lizenzpreisen von mehreren tausend Dollar gehandelt wurde.

Der Interbase-Code wurde von Borland später wieder geschlossen. Aus der kurzen Open-Source-Affäre war aber bereits das Projekt Firebird hervorgegangen, das seinerseits aktive Anhänger fand und sich bis heute weiterentwickelt. Gegenwärtig ist es in der Dritten Welt (namentlich in Brasilien) sowie in Osteuropa verbreiteter als hierzulande oder in den USA.

Die Anwender finden in Firebird eine solide und zuverlässige SQL-Datenbank, der allerdings einige der fortgeschrittenen Features fehlen. So gibt es weder Cluster noch Load Balancing und – schlimmer noch – auch keine Replikation, keine Volltextsuche, nur B-Tree-Indizes, keine Tabellen-Partitionierung und keine räumlichen Datentypen. Multi-Threading und Multi-Prozessor-Support kann der Admin nur alternativ, aber nicht gleichzeitig haben.

Dafür punktet Firebird mit einem stabilen und für viele Zwecke auch ausreichenden Funktionsumfang, einfacher Installation und guten Cross-Plattform-Fähigkeiten. Im zuletzt genannten Punkt übertrifft es beispielsweise auch PostgreSQL, dessen Windows-Port lange ein Schattendasein fristete.

Abbildung 3: Firebird bringt keine eigenen grafischen Tools mit – es gibt aber etliche freie und kommerzielle Werkzeuge für den Admin. Zu Letzteren gehört IB4Admin.

Ingres 2006

Ingres [12] ist ein Datenbank-Urgestein: Vor bereits mehr als 30 Jahren als Forschungsvorhaben der UC Berkeley entstanden, zählte es zu den ersten kommerziellen Datenbanksystemen überhaupt und bildete in seiner Geschichte mehrfach den Ausgangspunkt für weitere erfolgreiche Datenbankprojekte, darunter PostgreSQL und Informix. Computer Associates (CA), die zuvor die Firma Ingres gekauft hatten, entließ die Datenbank schließlich im Mai 2004 unter der selbst entwickelten CA Trusted Open Source License (CATOSL) in die Welt der freien Software.

Hier zählte Ingres wieder zu den Pionieren: eine der ersten Open-Source-Datenbanken mit ausgeprägten Enterprise-Fähigkeiten wie Replizierbarkeit, Möglichkeiten für parallele Abfragen, Partitionierung oder Grid-Tauglichkeit. Später verkaufte CA Ingres an eine Investment-Firma, die schließlich die Ingres Corporation gründete, die die Datenbank nun seit einigen Monaten als 2006 Community Edition unter der GPL verbreitet.

Oracle Express

Fast alle namhaften Hersteller kommerzieller Datenbanken bieten inzwischen eingeschränkte, aber kostenlose Einsteigerversionen an. Oracles Light-Ausgabe XE (Express Edition, [8]) erlaubt nur eine Instanz, die auch nur einen Prozessor benutzen kann, kein größeres Datenvolumen als 4 GByte verwalten darf und nicht mehr als 1 GByte Hauptspeicher verwendet.

Dem abgespeckten Oracle fehlen die meisten Data-Warehouse- und Hochverfügbarkeits-Features sowie ein paar Zuckerl des großen Bruders, etwa ISQL Plus. Der Hersteller gewährt für diese Version außerdem keinerlei Support – gleichwohl gibt es Handbücher, Tutorials und Foren, in denen der Anwender in vielen Fällen Hilfe findet.

Auf der Habenseite steht die Möglichkeit, Know-how im Umgang mit dem Branchenprimus zu erwerben. Oracles Führungsrolle reflektiert nicht zuletzt die Tatsache, dass etliche Konkurrenten spezielle Kompatibilitätsmodi bieten, um ihrem Vorbild möglichst nahe zu kommen. Das betrifft etwa den Firebird-Ableger Fyracle [9] oder den Postgres-Mutanten Enterprise DB [11], der speziell mit seiner Oracle-Kompatibilität wirbt.

Abbildung 4: Oracle Express bietet eine durchdachte Weboberfläche für die Administration. Der Objekt-Browser präsentiert hier eine Datenbanktabelle, die sich an derselben Stelle auch komfortabel anlegen, indizieren, editieren, übereignen, einschränken, abfragen oder verknüpfen ließe.

DB2 Express-C

IBMs Datenbank-Flaggschiff DB2 gehört neben Oracle und dem SQL-Server von Microsoft zu den kommerziellen Datenbanken mit den größten Marktanteilen. Es ist auf Mainframes (IBM Z-Series) oder Midrange-Rechnern (IBM I-Series) ebenso zu Hause wie unter Unix, Linux und Windows. Dabei nutzt DB2 das Parallelrechenvermögen der Großcomputer genauso aus wie die Möglichkeit, sich über mehrere kleinere Knoten verteilen zu können, und skaliert dabei bis zu einer maximalen Datenbankgröße von mehr als 16 TByte.

Die kostenlose Version Express-C [13], die es seit Februar gibt, ist jedoch auf zwei CPUs und maximal 4 GByte Hauptspeicher begrenzt. Auch fehlen ihr einige Zusatzfeatures, etwa die Warehouse Manager Tools, die Unterstützung für DB2 Connect oder High Availability Disaster Recovery. Punkten kann DB2 mit seiner Skalierbarkeit, dem breiten Anwendungsspektrum und ausgereiften Funktionen und einem gewachsenen Toolset für Kommandozeile, Web und GUI.

Abbildung 5: Das DB2 Control Center, die Kommandozentrale von IBMs Datenbank, ermöglicht auch in der freien Version eine zentralisierte, visuell unterstützte Datenbank-Administration.

Sybase

Sybase [11] zählt ebenfalls zu den altgedienten Enterprise-Datenbanken, die Firmengründung erfolgte im Jahr 1984. Zu den prominenten Anwendern gehörte beispielsweise das 2003 beendete Human Genom Project, das 1988 mit einer Sybase-Datenbank startete.

Über die Jahre hat sich – wie bei den Konkurrenten mit vergleichbar langer Geschichte – um die Datenbank herum eine ganze Umgebung aus Entwicklungstools, Administrationswerkzeugen oder Abfrage-Utilities entwickelt (Power Builder, Power Designer, SQL Anywhere Studio, Sybase Workspace und so weiter). Gegenwärtig orientiert sich Sybase neben Branchenanwendungen besonders auf mobile Datenbanklösungen.

Eine Episode aus der Sybase-Geschichte wirkt bis heute in ganz besonderer Weise fort: Der Sybase SQL Server bildete nämlich 1988 die Codebasis für die erste große SQL-Datenbank aus dem Hause Microsoft. Zwar trennten sich 1993 die Wege der Hersteller wieder und Sybase benannte 1995 die eigene Datenbank der besseren Unterscheidung wegen sogar in Adaptive Server Enterprise (ASE) um, doch bis heute ist die Portierung einer Windows-Anwendung, die auf Microsofts SQL Server beruht, besonders einfach, wenn unter Linux eine Sybase-Datenbank läuft.

Seit 1999 gibt es eine Linux-Ausgabe von Sybase, die schon unter den frühen 5er Versionen von Suse und Red Hat Linux lief. Damals wurden lediglich 64 MByte RAM und mindestens das Doppelte an freiem Plattenplatz vorausgesetzt. Das dürfte der heutigen kostenlosen Linux-Variante der Datenbank als Untergrenze sicherlich nicht mehr reichen, die andererseits nach oben auf eine CPU, 2 GByte RAM und ein maximales Datenvolumen von 5 GByte limitiert ist.

Abbildung 6: Bei manchen Datenbanken ist der Admin auf die Dokumentation angewiesen, für andere gibt es umfangreiche Sekundärliteratur – hier die Treffer bei Amazon mit dem Datenbanknamen als Suchbegriff.

Fazit

Ausgangspunkt bei der Wahl der passenden Datenbank ist immer der Bedarf. Soll sie sich in eine GPL-Anwendung einordnen, sind die kommerziellen Einsteigerversionen dafür ungeeignet. Wer trotzdem an eben eine dieser kommerziellen Light-Versionen denkt, muss die technischen Voraussetzungen erfüllen, denn diese Software lässt sich nicht in der eigenen Umgebung kompilieren und zurechtschnitzen.

Nach dieser Grundsatzentscheidung ist das Pflichtenheft im Licht der eingangs erläuterten Kurzsteckbriefe zu betrachten: Ergeben sich beispielsweise sehr hohe Anforderungen an die Verfügbarkeit, wird der Datenbank-Administrator nicht zu Firebird greifen, für das es weder Replikation noch Cluster gibt. Spielt dagegen die Verfügbarkeit gar keine Rolle und sind stattdessen nur die nackten Antwortzeiten von ausschlaggebender Bedeutung, kommt vielleicht MySQL mit einer transaktionslosen, aber schnellen Storage-Engine in Betracht. Wer besonders ausgeprägte Standardkonformität sucht oder eine raffinierte Indizierung benötigt, für den könnte sich in vielen Fällen PostgreSQL empfehlen.

Mit den speziellen Anforderungen an eine Business-Datenbank und zugleich komplexen Queries kommt wahrscheinlich Ingres am besten zurecht, deren Optimizer Mammutanfragen in Häppchen zerlegt. Heißt die Anwendung aber SAP, dann hat natürlich die vom selben Hersteller entwickelte und von ihm zertifizierte Max DB einen Vorteil.

Wo die GPL nicht Bedingung ist, bringen auch Oracle, Sybase oder DB2 gute Voraussetzungen mit. Sybase bietet sich dabei in besonderer Weise für die Migration vom Microsoft SQL Server auf eine Linux-Plattform an. DB2 Express-C spielt einen Vorteil aus, wo die Datenbank keine Größenbeschränkung haben soll. Oracle gilt als Quasi-Standard.

An einer Einzelfallprüfung führt aber kein Weg vorbei, eine einfache Daumenregel, nach der man eine Anwendung pauschal dieser oder jener Datenbank als am besten geeignete Ablage zuordnen könnte, gibt es nicht.