Die Entscheidung für ein bestimmtes Datenbankmanagementsystem ist nach meiner Überzeugung von essentieller Bedeutung für jedes Projekt.

Während ich früher der Meinung war, daß man seine Systeme möglichst datenbankunabhängig halten sollte, hat mich die Erfahrung gelehrt, daß dieses Ansinnen in der Praxis kaum sinnvoll realisiert werden kann.

Zum Einen würde das den Verzicht auf grundlegende —aber von Datenbank zu Datenbank unterschiedlich realisierte— Konzepte wie Stored Procedures bedeuten.

Zum Anderen erweist sich die fette Zwischenschicht, die die Unterschiede bei der Ansteuerung einzelner Datenbanken ausgleichen soll, bei fortschreitendem Projektverlauf zunehmend als Hemmschuh, weil sie dem dabei aufkommenden Wunsch, die funktionalen Spezifika eines Datenbanksystemes zu nutzen, im Wege steht.

Besonders ärgerlich ist das dann, wenn man sich zwischenzeitlich halt doch schon längst auf eine bestimmte Datenbank festgelegt hat (Zum Beispiel, weil man einfach nicht weiter auf die Verwendung von Stored Procedures verzichten wollte oder konnte) und nun nur noch die überladene Zwischenschicht als Relikt aus alten Zeiten im Wege steht.

Konsequenterweise bin ich mittlerweile zu dem Schluß gelangt, daß es umgekehrt schlicht am effektivsten ist, Farbe zu bekennen und sich voll und ganz auf ein bestimmtes Datenbankmanagementsystem einzulassen, d.h. auch dessen spezielle Features und Eigenheiten zu nutzen.

Umso verheerender wird es natürlich dann, wenn man feststellen sollte, daß man in einer Sackgasse gelandet ist, weil man sich wohl doch auf die falsche Datenbak festgelegt hat, z.B. weil jene den mittlerweile gestiegenen Anforderungen eines konsequent ausgebauten Projektes nicht mehr gewachsen ist.

Tatsächlich ist es für ein Datenbanksystem schwierig, allen charakteristischen Änderungen der Anforderungen im Projektverlauf gerecht zu werden.

Typischerweise beginnt alles mit einem kleinen, übersichtlichen Projekt, welches eigentlich nur möglichst schnell fertig sein sollte, und das dabei halt auch noch seine Daten —das sind ja nur ein paar Datensätze— irgendwo ablegen muß.

Dazu eignen sich natürlich am Besten schnell erlernbare und leicht bedienbare Tools mit einer niedlichen grafischen Benutzeroberfläche mit denen man umgehend vorzeigbare Ergebnisse zu Stande bringt und die das Zielsystem von ihrem zusätzlichen Ressourcenverbrauch her nicht wesentlich belasten.

Wird das Projekt danach auf diesem Niveau tatsächlich eingestellt, ist ja vielleicht auch alles in Ordnung.
Vielleicht aber zeigt das eben noch so kleine niedliche Tool ja auch plötzlich die Zähne und trumpft mit ganz erheblichen Laufzeit-Lizenzkosten oder anderen, z.B. technischen Schwierigkeiten beim Deployment (z.B. aufgrund erheblichen Ressourcenverbrauchs oder wegen möglicher DLL- Konflikte) auf....
...was aber immer noch nicht so schlimm wäre, wie eine Möchtegern-Datenbank, welche nicht stabil und zuverlässig läuft und daher laufend bei den Kunden für Datenverlusten und somit Ärger sorgt.

Diejenigen Projekte, die weiterentwickelt werden, ändern sich sowieso drastisch in ihren Anforderungen:

Die leichte Erlernbarkeit und die Niedlichkeit der Entwicklungsoberfläche verlieren wesentlich an Bedeutung.

Dafür soll die Datenbank nun aber eine große Anzahl von Tabellen mit einer Vielzahl von indizes und einer Unmenge von Datensätzen souverän handhaben können.

Ausserdem soll sie nicht nur bei hoher Nebenläufigkeit trotz rasanter Verarbeitung großer Datenmengen immer auch die Konsistenz der verwalteten Daten gewährleisten, sonden auch schnellen Client/Server-Zugriff auf beliebige Datensätze im Datenbestand ermöglichen.

Die ACID-Kriterien der Transaktionsverarbeitung gewinnen "plötzlich" grundlegende Bedeutung und Stabilität und Zuverlässigkeit waren ja eigentlich sowieso schon immer selbstverständlich.

Trotz allem sollte dieses universelle Wunderkind möglichst billig sein und die Laufzeitlizenzen sollten am Besten gleich gar nichts kosten. Wir kennen das ja....

Erstaunlicherweise gibt es mit dem Firebird-Datenbankmanagementsystem tatsächlich ein Tool, das nach meinen Erfahrungen alle wesentlichen Anforderungen erfüllt:

Und das Beste kommt erst noch:

Klingt das fast zu schön, um wahr zu sein?

Einen Haken —wenigstens einen— muß es da doch geben?

Tatsächlich gibt es den:

Das Firebird-RDBMS ist weder schnell erlernbar noch leicht bedienbar. Von einer niedlichen Entwicklungsoberfläche kann man nur träumen.
Stored Procedures oder Trigger zu entwickeln ist selbst für den erfahrenen Entwickler sehr unbequem und UDFs zu programmiern ist geradewegs gefährlich.

Sie brauchen also schon einen erfahrenen Entwickler, wenn Sie auf Basis der Firebird- Datenbank ein Projekt aufsetzen wollen.