PHP PGAdmin, das PHP-gestützte Web-Front-End für Postgres in Aktion.

MySQL und Postgres sind seit langer Zeit als Open Source verfügbare Datenbanksysteme und vor allem als Back-Ends für Web-Anwendungen beliebt. Im direkten Vergleich müssen beide zeigen, was sie können.

Postgres (ganz offiziell: PostgreSQL) ist ein objekt-relationales Datenbank-Managementsystem (DBMS), dessen Source-Code und Dokumentation unter der BSD-Lizenz frei erhältlich sind und an dem von zahlreichen Entwicklern weltweit gearbeitet wird. Es läuft auf fast allen Plattformen wie Solaris, SunOS, HPUX, AIX, Linux, Irix, FreeBSD und den meisten Unix-Varianten. Die aktuelle stabile Version ist 7.0.3.

Die Entwicklung von Postgres begann 1977 an der Berkeley-Universität mit dem Namen Ingres. Von 1986 bis 1995 entwickelte Michael Stonebraker, Professor an dieser Universität, ein objekt-relationales DBMS namens Postgres (Nach-Ingres). Die Firma Illustra vermarktete den Code zu einem kommerziellen Produkt und wurde später von Informix aufgekauft. 1994 fügten zwei Berkeley-Doktoranden, Jolly Chen und Andrew Yu, dem ODBMS SQL hinzu und benannten es in Postgres95 um.

Relativ rasch wird ihnen klar, wie groß das Interesse an einem Open-Source-DBMS ist: Die Mailing-Liste hat damals bereits über 1000 Subscriber. Mit insgesamt 250.000 Zeilen C-Code braucht man aber viel Zeit zur Einarbeitung, man musste “einige wenige Leute mit viel Zeit finden, nicht viele Leute mit etwas Zeit” (Jolly Chen). Heute gibt es etwa 15 Stamm-Entwickler, die den Code ihres jeweiligen Moduls überblicken, und zahlreiche weitere freiwillige Entwickler. Neue Features können wegen der hohen Entwicklerzahl rasch hinzugefügt werden.

Postgres – Installation

Die Installation von Postgres ist einfach, die meisten Linux-Distributionen enthalten entsprechende Packages. Bei einigen Distributionen, zum Beispiel Mandrake 7.x, richtet das Installationsprogramm Postgres vollständig ein. Ansonsten kann der Source von der Postgres-Website heruntergeladen und selbst kompiliert werden. Das Anlegen von Datenbanken ist ebenfalls sehr einfach und wird in der ausgezeichneten Dokumentation gut beschrieben.

Postgres – Standardfunktionen

Postgres hält sich weitgehend an den SQL92-Standard. Transaktionen, Fremdschlüssel und Benutzersichten (Views) sind kein Problem; seit Version 7.0.2 auch Outer Joins. Verschachtelte Abfragen, so genannte Subselects mittels SELECT sind möglich:

SELECT city FROM weather
   WHERE temp_lo = (SELECT max(temp_lo) FROM weather);

Postgres – Datenintegrität/Transaktionen

Fremdschlüssel (Foreign Keys) helfen dem Entwickler dabei, die Korrektheit von Daten mit Datenbankmitteln festzustellen: Foreign Key Constraints stellen eine Abhängigkeit zwischen einer oder mehreren Spalten einer Tabelle mit einer oder mehreren Spalten einer anderen Tabelle her. Beim Verändern von Daten wird diese Abhängigkeit überprüft, inkonsistente Änderungen sind nicht mehr möglich.

Postgres ist eine ACID-Datenbank (siehe Kasten “Transaktionen …”:

• Atomicity
• Consistency
• Isolation
• Durability

Transaktionen werden auf Row-Ebene unterstützt und durch eine interne Versionsverwaltung (Multi Version Concurrency Control) sichergestellt, ein Verfahren, das erheblich schwerer und aufwändiger zu implementieren ist als das gängige Locking anderer Datenbanksysteme. Mit dem MVCC-Verfahren warten Leser nicht auf Schreiber: Jede Transaktion sieht einen entsprechenden Datenbank-Snapshot, Datenänderungen von gleichzeitig laufenden Änderungenstransaktionen werden in diesem Snapshot nicht nachgefahren.

Postgres – Erweiterte Funktionalität

Wie in fast allen professionellen Datenbanksystemen sind Trigger und Stored Procedures bekannt. Nicht implementiert ist derzeit dagegen die Möglichkeit, Datenbanken zu replizieren.

PHP PGAdmin, das PHP-gestützte Web-Front-End für Postgres in Aktion.

Postgres ist Katalog-basierend. In dem Katalog werden nicht nur die Tabellen, sondern auch Datentypen, Funktionen, Zugriffsmethoden gespeichert. Das macht dieses Datenbanksystem leicht erweiterbar. Sogar Vererbung ist möglich:

CREATE TABLE cities (
 name       text,
 population float,
 altitude   int
);

CREATE TABLE capitals (
 state      char(2)
) INHERITS (cities);

Die Instanzen der Tabelle capitals erben alle Attribute des Elternknotens cities ( name, population, altitude).

Um alle Städte – auch die Hauptstädte – zu erfragen, die höher als 500 Meter liegen, kann das auf der nächsten Seite angegebene SQL-Statement verwendet werden:

SELECT c.name, c.altitude
 FROM cities* c
 WHERE c.altitude >500;

Der Stern * teilt dem SQL-Parser mit, dass die Query die Tabelle cities und alle von ihr abstammenden Tabellen in der Klassenhierarchie abfragt.

Das relationale Modell kennt nur atomare Attribute, Postgres aber auch Arrays:

CREATE TABLE SAL_EMP (
 name            text,
 pay_by_quarter  int4[],
 schedule        text[][]
);

INSERT INTO SAL_EMP
 VALUES (`Ulrich',
 `{10000,12312, 9423, 18400}',
 `{{"meeting", "beer"}, {}}');

INSERT INTO SAL_EMP
 VALUES (`Tom',
 `{14000,11000, 9200, 12000}',
 `{{"meeting", "lunch"}, {}}');

SELECT name 
 FROM SAL_EMP
 WHERE SAL_EMP.pay_by_quarter[1] 
       < SAL_EMP.pay_by_quarter[2];

Es wird eine Tabelle mit einem eindimensionalen und einem zweidimensionalen Array angelegt, zudem eine Zeile eingefügt. Danach werden alle Namen von Mitarbeitern abgefragt, die im zweiten Quartal mehr als im ersten Quartal verdient haben.

Trigger und Stored Procedures

Trigger und Stored Procedures werden in Netzwerken verwendet, um Server-Roundtrips zu minimieren. Beide werden innerhalb der Datenbank ausgeführt, es gibt keinen Netzwerk-Traffic zwischen Applikation und Datenbank. In einem normalisierten Datenmodell werden Trigger vor allem fürs Auditing und für die Performance-Steigerung benötigt, wenn sie für die Anwendung transparent sein sollen:

• Auditing ist das Speichern von ändernden Zugriffen auf Objekte: Ein Statement ändert einen Datensatz, ein Trigger hält diese Änderungen in einer Audit-Tabelle fest.
• Zur Performance-Steigerung werden Datenmodelle häufig denormalisiert. Die Information wird redundant gemacht, weil dann mit entsprechenden Indizes schnellere Zugriffe möglich sind.

Stored Procedures sind ein weiteres Mittel, Applikationslogik in die Datenbank zu verlagern. Es handelt sich um richtige Programme mit Kontrollstrukturen, die innerhalb der Datenbank ausgeführt werden und Ergebnisse liefern können. So kann beispielsweise eine HTML-Seite innerhalb der Datenbank aufbereitet und komplett an den Webserver zurückgeliefert werden.

Trigger und Stored Procedures erstellt man in einer Programmiersprache namens PG/SQL, die sich an Oracles PL/SQL anlehnt, oder in PL/Tcl oder PL/Perl. Es kann also innerhalb der Datenbank mit diesen beiden Skriptsprachen entwickelt werden. Insgesamt sind der Postgres-SQL-Dialekt und die datenbankeigene Programmiersprache denen von kommerziellen Datenbanken fast ebenbürtig und Applikationen können mit vertretbarem Aufwand portiert werden.

Postgres – Schnittstellen und Clients

Postgres bietet zahlreiche Interfaces zu anderen Programmiersprachen oder Systemen an, unter anderen:

• LIBPQ, LIBPQEASY
• ECPG und LIBPQ++ für C++
• ODBC
• TCL
• Python
• Ruby
• JDBC
• Perl
• PHP
• Delphi

Interessant für Umsteiger sind Migrationswerkzeuge von Microsoft Access. Eher noch in den Kinderschuhen steckt PHP PGAdmin, das Postgres-Äquivalent zu PHP MyAdmin, dem beliebten Web-Front-End für MySQL. Sicherlich ist es nicht ganz leicht, die höhere Komplexität von Postgres auf ein ergonomisches Web-Interface abzubilden. Der Akzeptanz von Postgres wird ein solches Tool aber stark zugute kommen.

Wer mag, kann auf http://pgdemo.acucore.com nach Herzenslust Datenbanken und Tabellen anlegen und damit das Interface und die Datenbank näher kennenlernen. Die meisten grafischen Front-Ends wie Glider und GtkSQL sowie KSQL arbeiten auch mit Postgres zusammen. Oft haben die Entwickler jedoch MySQL als Ausgangspunkt genommen, so dass Postgres-spezifische Features nur mangelhaft unterstützt werden.

Zweiter Kandidat: MySQL

MySQL [4] ist ein relationales Datenbank-Managementsystem (DBMS) unter der GPL. Sein Ursprung liegt laut [1] beim 1979 von Michael Widenius für die schwedische Firma TcX entwickelte Datenbank-Tool UNIREG. Aus diesem Projekt entstand 1994 MySQL, das bis heute weiterentwickelt wird. MySQL gibt es heute für Linux, FreeBSD, Solaris und weitere kommerzielle Unix-Varianten, die 32-Bit-Versionen von Windows sowie OS/2. Die offizielle Aussprache ist Mei-es-kju-ell. Leute, die “Mei Sequel” sagen, werden aber nicht strafrechtlich verfolgt.

MySQL ist schon recht lange für private Nutzer unter Linux kostenlos verfügbar und hat sich zu einem Quasistandard für Web-Datenbanken entwickelt. Seit vorigem Jahr steht MySQL unter der GPL. Damit haben ambitionierten Nutzer die Möglichkeit, noch fehlende Komponenten zu ergänzen. Zu beachten ist aber, dass ältere MySQL-Versionen immer noch unter den alten, recht komplizierten Lizenzbedingungen stehen.

Nach wie vor besteht die Möglichkeit, aktuelle MySQL-Versionen unter einer kommerziellen Lizenz zu erwerben, wenn die Teile der Datenbanksoftware in kommerzielle proprietäre Produkte eingebunden werden sollen. Rechtlich problematisch ist allerdings, was die Firma MySQL AB als Inhaberin des Copyrights unter Linking versteht: Dazu soll es nämlich schon genügen, wenn ein proprietäres, kommerziell vertriebenes Produkt auf MySQL angewiesen ist, um zu funktionieren.

MySQL – Installation

MySQL ist Bestandteil aller gängigen Linux-Distributionen. Auf Wunsch richten die Installationsprogramme das Datenbanksystem auch ein. Binaries gibt es auf [1] als Tarballs für alle gängigen Unix-Systeme und als RPMs für Linux auf Intel-Architektur. An spezielle Distributionen angepasste RPMs existieren dort nicht. Die Installation ist für alle Architekturen sehr ausführlich in der Dokumentation beschrieben.

MySQL – Standardfunktionen

MySQL bietet Konformität zum Standard Entry Level SQL92. Neuere MySQL-Versionen unterstützen Transaktionen, aber Benutzersichten (Views) und verschachtelte Anfragen sieht MySQL nicht vor, diese müssen emuliert werden. Dazu das folgende Beispiel:

Person(Person_ID, Name, Vorname, Anschrift)
Telefonate(Telefonat_ID, Person_ID, Rufnummer)

Es seien also die beiden Tabellen Person und Telefonate mit den entsprechenden Attributen gegeben. Mit geschachtelten Anfragen wäre es ohne weiteres möglich, Name und Vorname sowie Anschrift der Person herauszufinden, die eine bestimmte Rufnummer gewählt hat. Eine entsprechende Anfrage sieht folgendermaßen aus:

SELECT Person.Name, Person.Vorname, 
           Person.Anschrift FROM Person
               WHERE Person.Person_ID IN
               (
               SELECT Telefonate.Person_ID FROM Telefonate
                       WHERE Telefonate.Rufnummer="0815"
                )

Das ist in MySQL unmöglich und muss oft anwendungsseitig gelöst werden. Dazu sind Zwischenergebnisse zu speichern und auszuwerten. Problematisch wird es, wenn sich der Datenbestand während dieses Prozesses ändert. Zum Glück kann man mit MySQL geschachtelte Abfragen emulieren. In [2] steht dazu, dass Anfragen der Form

(1) SELECT * FROM table1 
    WHERE id IN (SELECT id FROM table2);  
(2) SELECT * FROM table1 
    WHERE id NOT IN (SELECT id FROM table2);

nicht unterstützt werden. Der gleiche Effekt lässt sich aber auch folgendermaßen erreichen:

(1) SELECT table1.* FROM table1,table2 
    WHERE table1.id=table2.id; 
(2) SELECT table1.* FROM table1 
    LEFT JOIN table2 ON table1.id=table2.id 
    WHERE table2.id IS NULL;

MySQL – Datenintegrität/Transaktionen

Die Sicherung der Datenintegrität obliegt bei der Verwendung von MySQL dem Anwendungsprogrammierer. Dieser muss mit genügender Kenntnis des Datenbankschemas seine Datenbankanwendung so gestalten, dass die Datenintegrität nicht gefährdet wird. Bei unserer Personen-Telefonate-Datenbank kann er zuerst mit einer Anfrage der Form

SELECT * FROM Person WHERE Person_ID="100";

sicherstellen, dass eine Person mit der Person_ID100 existiert.

Im nächsten Schritt kann dann in die Telefonate-Tabelle ein Telefonat eingetragen werden, das durch die Person mit der Person_ID100 geführt wurde. Existiert keine solche Person, kann eine entsprechende Fehlermeldung generiert werden. Das Schlüsselwort FOREIGN KEY wird von MySQL zwar akzeptiert – es gibt jedenfalls keine Fehlermeldung -, jedoch vollständig ignoriert.

Für Transaktionen benutzen aktuelle MySQL-Versionen transaktionssichere Tabellen der Berkeley Database (DBD). Dieser Tabellentyp ist beim Anlegen explizit anzugeben. Auch nachträgliche Konvertierungen mittels ALTER TABLE sind möglich; für Syntax und Details sei wieder auf die Dokumentation verwiesen.

MySQL – Erweiterte Funktionalität

MySQL bietet zahlreiche syntaktische Goodies, um dem Anwendungsentwickler das Leben zu erleichtern. Beispielsweise REPLACE anstelle von DELETE und INSERT, das SHOW-Statement, um Informationen über Tabellen zu erhalten. Selbst Zugriffe auf Tabellen aus anderen Datenbanken als der aktuellen sind möglich. Eine komplette Liste aller Erweiterungen ist in der Dokumentation enthalten. Wer auf Portabilität angewiesen ist, sollte diese Funktionen nur mit der größten Vorsicht nutzen, da sie in vielen Fällen in anderen Datenbanken nicht oder anders als gedacht funktionieren.

Trigger und Stored Procedures sind derzeit nicht implementiert, Letztere sollen jedoch in einer der künftigen Versionen möglich sein.

Ein deutliches Plus gegenüber Postgres ist die Replizierbarkeit von Datenbanken. Ausgehend von einer Master-Datenbank lässt sich eine Slave-Datenbank anlegen, an die bei Bedarf Anfragen weitergeleitet werden. Der Master erzeugt dazu ein binäres Logfile, das der Slave bei einem Connect aktualisiert. Dieses Verfahren steigert sowohl die Performance als auch die Ausfallsicherheit. Schreibende Zugriffe auf die Datenbank müssen jedoch immer auf den Master erfolgen.

MySQL kennt keine Benutzersichten (Views). Diese können aber leicht von der Datenbankanwendung nachgebildet werden. Schließlich muss das Anwendungsprogramm sowieso die Daten aus der Datenbank lesen, um sie dann darzustellen. Zwischen dem Lesen und der Darstellung kann also noch eine Vorverarbeitung erfolgen, die für den Nutzer die relevanten Daten herausfiltert.

MySQL – Schnittstellen und Clients

In der Regel wird kein halbwegs normaler Nutzer ausschließlich manuell SQL-Anweisungen eintippen wollen. (Ausnahmen bestätigen die Regel.) Außerdem kann ja beispielsweise von einem Biologen nicht verlangt werden, dass er SQL lernt, um die Ergebnisse seiner Experimente in eine Datenbank einzufügen. Schließlich muss eine Datenbankanwendung (siehe Kasten “Glossar”) programmiert werden. Damit der Nutzer über dieses Anwendungsprogramm die Daten in der Datenbank manipulieren kann, müssen entsprechende Schnittstellen (Application Programming Interface, API) bereitgestellt werden. Bei MySQLsind das die folgenden:

• C-API [2]
• JDBC [12]
• Pascal-API [7]
• PHP-API [6]
• TCL-API [13]
• C++ API [9]
• ODBC [10]
• Perl-DBI-API [11]
• Python-API [8]
• Delphi-API [14]

Für interaktive Web-Inhalte haben sich von privaten bis zu ernsthaften kommerziellen Seiten so genannte LAMP-Projekte bewährt, LAMP steht für: Linux, Apache, MySQL, PHP. Interessierten Lesern, die sich mit der Internet-Programmierung mit PHP und MySQL beschäftigen wollen, sei [5] empfohlen.

MySQLGUI ist das offizielle GUI-Front-End von MySQL.

Das Web-Front-End PHP MyAdmin erleichtert schon seit einiger Zeit den Alltag für MySQL-Administratoren. Gnome- beziehungsweise Gtk-basierte Front-Ends sind Glider und GtkSQL, jeweils von Sourceforge zu beschaffen. Direkt von der MySQL-Website kann man MySQLGUI herunterladen (siehe Bild). Dieses Tool braucht das FLTK-Toolkit und dient dem Monitoring und der Administration von MySQL-Datenbanken. Schon weit gediehen ist das KSQL-Projekt, das es sich zum Ziel gesteckt hat, ein datenbankunabängiges Front-End für den KDE-Desktop zu schaffen. MySQL-Funktionen werden derzeit am besten unterstützt.

Mit Kmysql steht im KDE ein GUI-Interface für viele SQL-Datenbanken zu Verfügung. Einige Funktionen benötigen jedoch MySQL.

Fazit

Beide Kandidaten sind zuverlässige und stabile Open-Source-Datenbanken, die sich vor allem, aber nicht nur als Back-Ends für dynamische Websites eignen. Postgres bietet jedoch deutlich mehr Möglichkeiten als MySQL, das nicht alle Standardanforderungen an ein relationales Datenmanagement-System erfüllt. Postgres hingegen geht mit objekt-relationalen Features wie Vererbung und freien Datentyp-Definitionen sogar darüber hinaus. Es eignet sich somit besser als MySQL für die Umsetzung komplexer Datenmodelle. In die Postgres-Entwicklung ist seit Version 7.0.x wieder Schwung gekommen und zahlreiche Betreiber untersuchen derzeit Umstiegsmöglichkeiten auf dieses System.

Für MySQL spricht die sehr große Nutzergemeinde, die vor allem im Zusammenhang mit PHP eine Unzahl von Web-Applikationen entwickelt hat. In vielen Fällen benötigt man nur eine simple und relativ statische Datenstruktur und kann auch Redundanzen in Kauf nehmen. Dann bietet MySQL unter Umständen sogar Performance-Vorteile, die bei hohem Traffic mit der neuen Möglichkeit der Replizierbarkeit auf verschiedene Hosts noch ausgebaut werden können.

Wer nur freie Software entwickelt, liegt lizenzrechtlich mit beiden Datenbanken auf der sicheren Seite. Aufgrund der großzügigen BSD-Lizenz hat man auch bei kommerziellen, auf Postgres beruhenden Applikationen keine Sorgen. Wer hingegen proprietäre Produkte mit MySQL vertreiben will, sollte sich die Lizenzbedingungen auf der MySQL-Website ganz genau anschauen.

Frühere Postgres-Versionen waren oft nicht stabil und es kam des öfteren sogar zu Datenverlusten. Das Postgres-Entwicklerteam hat viel Zeit in Regression-Tests investiert, die eine hohe Stabilität und Datensicherheit garantieren. Releases gibt es inzwischen erst nach längeren Beta-Phasen. Die neuen Versionen von Postgres sind erheblich performanter geworden (siehe Kasten “Benchmarks”).

Gravierende Stabilitätsprobleme sind bei MySQL nicht bekannt. Mit dem neuen Feature der Replizierbarkeit geht das System noch einen erheblichen Schritt weiter in Richtung erhöhte Ausfallsicherheit. Vor allem zusammen mit PHP erreicht MySQL gute Performance-Werte bei Web-Anwendungen (siehe Kasten “Benchmarks”). Zur Performance-Optimierung sei hier ein Vortrag des MySQL-Gründers Michael Widenius empfohlen [15].

Welches Pferd für welche Rennbahn?

Wo kann man MySQL und Postgres sinnvoll einsetzen? Für zwei große Bereiche sind beide hervorragend geeignet: Das sind zum einen die Programmentwicklungen und zum anderen Internet-Datenbanken. Kommerzielle Datenbank-Managementsysteme wie beispielsweise Oracle oder DB2 sind zwar leistungsfähiger, aber auch teurer. In der Regel macht es also keinen Sinn, sich ein solches Produkt zu kaufen, bevor überhaupt Anwendungen dafür entwickelt sind.

Das ist die Chance der freien Datenbanken. Die komplette Entwicklung einer Datenbankanwendungen kann sowohl auf MySQL als auch auf Postgres erfolgen. Das wird beispielsweise bei PHP-Anwendungen dadurch ermöglicht, dass sämtliche Anfragen in SQL übergeben werden. Bei geschickter Programmierung müssen im Falle einer späteren Portierung auf ein großes Datenbank-Managementsystem lediglich die programmspezifischen Funktionen durch die entsprechenden Funktionen dieses DBMS ersetzt werden.

Das zweite Einsatzgebiet sind die bereits erwähnten Internet-Datenbanken. Im Internet kommt es hauptsächlich auf gute Performanz an. Außerdem sind Schreiboperationen auf Datenbanken im Internet eher selten. Hier kommt MySQL sogar die fehlende Funktionalität zu Hilfe: Je weniger geprüft werden muss, desto schneller ist in der Regel ein DBMS. Sollte die jeweilige Internet-Anwendung jedoch ziemlich komplex werden und beispielsweise auch das Einfügen in mehrere Tabellen realisieren, dann ist Postgres wohl doch die bessere Wahl. An dieser Stelle überwiegen dann wieder die Nachteile der fehlenden Funktionen.

An dieser Stelle sei aber wieder (siehe Kasten “Benchmarks”) der Hinweis gestattet, dass all diese Leistungsmessungen ihre Tücken haben. Nur zu oft stellt man fest, dass jedes System bei einem speziellen Benchmark das beste ist. ( uwo)