Firebirds Vorteil liegt darin, dass es sehr schlank und X platform ist. Außerdem finde ich es schon praktisch, dass es anonyme Blöcke gibt, die wie eine normale
Query genutzt werden können.
Der Nachteil ist, dass es vieles schlechtweg gar nicht kann, oder nur um 5 Ecken und 7 Kanten...
Das Langsamwerden kann sich mit der Art wie
FB Transaktionen verwaltet erklären. Man sollte NIEMALS eine Transaktion länger auflassen als nötig. Ganz einfach weil
FB sicherstellt, dass diese Transaktion weiterhin die
DB zum Zeitpunkt vom Transaktionsstart sieht. Selbst wenn zwischendurch viel geändert wurde.
FB löst das indem Records versioniert werden. Aber genau hier entsteht die Performancefalle, da er sich, mit etwas pech, an 10.000 Versionen
pro Record entlanghangeln muss wenn du in deiner Transaktion etwas löschst.
Gutes Beispiel sind Connectionpools. Wenn ein Service seit 3 Tagen eine Transaktion duch eine Connection im Pool aufhält, dann sieht diese Transaktion den Zustand von vor 3 Tagen. Jede Änderung seitdem erzeugte eine neue Version des Records und das bremst die Zugriffe auf diese Tabelle aus.
Beendet man diese andauernde Transkation wird es nicht lange dauern und
FB wird alleine aufräumen und die Tabelle wieder neu so anordnen, dass sie möglichst performant genutzt werden kann.
FB ist relativ einfach zu bedienen, weil man in wenigen Tagen den kompletten Umfang erfassen kann. Aber Fallen gibt esfür viele, die von anderen
DBMS' kommen (ich hebe hier mal selbst den Arm
), da Tansaktionen und Recordversionen doch anders gehandhabt werden und auch eine gewissen Sorgfalt benötigen.
Momentan können in manchen Situationen/Anwendungsgebieten die teilweise großen Implementierungslücken in
FB überwiegen.
FB 3 wird einiges neues auf den Tisch bringen, aber bis dahin ist es
IMHO nur für den embedded Betrieb interessant (Wobei SqLite da besser punktet). Oder da wo man ein
DBMS braucht, was komplett ohne Admin klar kommt und was nicht skalieren können muss.
Das klingt vllt strenger als es gemeint ist, denn
wirklich skalieren können die wenigsten Apps, selbst wenn sie Multi-Tier Designs sind. Und viele Designs für skalierende Apps können eine schlecht/gar nicht skalierende
DB oftmals besser verschmerzen als man denkt.
Wir werden zum Beispiel zukünftig stärker als bisher durch
verteilte Caches skalieren und somit die doch extremen krassen Kosten von Cluster-fähigen
DBMS' ignorieren können.
Das
DBMS ist dann nur noch ein Mittel der Wahl um Daten einfach ablegen und auslesen zu können (wenn der Cluster aus Caches es nicht schon vorhält)