Firebird: Pro und Kontra oder auch Alternativen

[mkinzler]

Ihr hättet halt die richtigen Komponenten Testen sollen (IBDAC, FIBplus)

[IBExpert]

Ich frag mich immer was andere so gerne falsch machen um den Firebird Server als lahme Gurke
zu verkaufen und das als Argument dafür zu bringen, das nur MS SQL und Oracle die Lösung aller
Probleme sind.

Eigentlich frag ich mich das aber nicht wirklich, denn ich hab fast täglich mit solchen Kandidaten
zu tun und frag mich wirklich, welche Ignoranz man haben muss um so einen Schrott zu programmieren.
Nun denn, meist bezahlen die Geld dafür das ich denen weiterhelfe.

Wenn jeder so in Delphi programmieren würde wie ich das manchmal in der Datenbank sehe, dann könnte
man auch sagen Delphi wäre schrott, mit Visual Studio geht das alles von alleine. Sehr lustig
fand ich vor kurzem die Speicherung von Daten in TStringlist Lines bei denen sich in jeder
Line wieder weiter TStringlists befinden, bei denen sich in jeder Line wieder weiter
TStringlists befinden, usw .... Wenn man sich dann wundert das der Zugriff in so einer
Baumstruktur via IndexOf grottenlahm ist, dem muss man leider erst mal ein paar Grundlagen
erklären. In diversen Kreisen wagt man ja zu behaupten, das man mit Delphi ja eh nicht ernsthaft
arbeiten kann, aber hier im Delphi Forum ist man damit eh auf dem Holzweg, zum Glück.

Mal was aus der Praxis über Datenbankprojekte:

Beispiel: Anwendung beim Kunden für viel Geld vom Softwarehaus gekauft, sobald die Software startet
steht die älteste aktive Transaktion und das System wird immer langsamer (das Problem kennt nicht nur
IB/FB). Kunde meckert beim Hersteller, Hersteller sagt, er sei nicht Schuld, das wäre die Datenbank,
er soll doch von IB umstellen auf Oracle. Aktueller Wert für Insider: OAT 200.000, next 3.000.000
Wenn einen das nicht interessiert womit das zusammenhängt sollte man nicht Programmierer werden.
Der Kunde ist auf jeden Fall ziemlich quakig, aber seit er von uns weiss das der Datenbankserver
selbst nicht die Ursache ist, sondern ein ignoranter Softwarehersteller, weiss er jedenfalls,
das es eine Lösung geben kann. Er muss halt nur noch mal seinen Softwarehersteller "überreden"!

noch ein Beispiel: sehr großer Kunde programmiert Software auf Basis C++ und Postgresql selbst.
Verarbeitung von täglich 50000 Anrufaufträgen über 150 ISDN parallele Leitungen in ingesamt 6 Linux
Rechnern, ergibt insgesamt ca 600000 Operationen pro Monat. Das System bricht unter Last hoffnungslos
zusammen und der Datenbankserver reagiert auf gar nichts mehr. Kunde fragt bei HK-Software ob man da
nicht was machen könnte. Wir haben das System umgestellt auf Firebird und Phyton Scripte und es
läuft wie erwartet. Die Umstellung der Datenbank war auch verbunden mit der Umstellung der Prozesse.
Das Originalsystem hat in kleinen Testumgebungen immer gut funktioniert, aber unter echter Last
reichte das eben nicht. Hier musste ein Webserver für Dateneingaben angebunden werden, einige
anderen Schnittstellenprogramme liefen auch parallel.

Postgresql hat keinen Superserver, ist also selbst für viele simultane Zugriffe auf db Ebene
eher nicht geeignet, daher auch meist im Zusammenspiel mit irgendeiner Middleware bei größeren
Installationen benutzbar. Viele glauben das das eine Stärke sei, das andere Server auch mit einer
großen Anzahl an Connections keine Probleme hat wollen viele nicht glauben, weil die eigene
favorisierte Plattform das eben nicht kann. Postgresql kommt bei der Garbage Collection zumindest
bei diesen Anforderungen nicht mehr mit. Auf Basis Firebird geht das auch ohne den ganzen Adminquatsch
(bitte mir jetzt nicht die 500 möglichen Parameter in Postgresql erklären). Vielleicht könnte
Postgresql das auch leisten, es hat aber im Projekt die erforderlichen Leistungen nicht
erbringen können.

noch ein Beispiel: dpa System Volltextsuche läuft auf einem simplen Dualprozessor Dell Server, einige
GB RAM (ich meine der hatte mal 15GB) und RAID PLatte. DB ist ca 30-40 GB groß, tagsüber arbeiten
auf dieser Kiste ca 150 Redakteure gleichzeitig und es rödeln noch diverse Clients schreibend auf
der DB, um neueste Meldungen aus aller Welt von allen möglichen Diensten in die DB zu schreiben.
Insgeamt sind die Daten von 18 Monaten drin, ca 4 Millionen Dokumente.

Ganz wichtige Frage für den Kunden: Wann hat die Volltextsuche die neuesten Daten im Index? Bei unserer
Lösung auf Basis von Firebird und einem in Delphi geschriebenen Service werden die Daten via Eventalerter
erkannt und umgehend in die globale Indextabelle eingetragen, stehen also dort nach dem Commit
mit einem simplen containing Befehl zur Verfügung. Das macht auch google nicht ( mit zugegeben
noch wesentlich mehr Daten, aber eben für diesen Kunden nicht sinnvoll einsetzbar).

Die dpa ist extrem sensibel in Bezug auf Geschwindigkeit und auf Betriebssicherheit, denn wenn nachmittags
für ca eine Stunde der Server ausfällt, dann sind am nächsten Tag die Zeitungen in Deutschland noch
weniger lesenswert als sowieso schon. Der Server macht Volltextsuche und ist gleichzeitig DB Server
für alle Clients.


Fazit:

Bei allen Lösungen macht es schon Sinn, das man sich mit den benutzten Werkzeugen auseinander setzt.
Bei Datenbanken erwarten viele aufgrund der Austauschbarkeit durch die SQL Sprache einfach zu viel.
Wenn man Leistung braucht bringt es nichts, einfach irgendein SQL auf Basis irgendeines gruseligen
Datenmodells auszuführen und dann zu erwarten, das die gerade gewählte Plattform das gefälligst selbst
optimieren soll.

Wenn ich mir so anschaue was Kunden auch in Delphi schon verbrochen haben, dann erwartet man irgendwann
eben nicht mehr so viel und ist um so mehr positiv überrascht wenn der Kunde sich doch schon intensiv
mit Details seines Tuns auseinander setzt.

Ich kann jedem aber glaubhaft versichern das bei entsprechender Programmierung der Firebird Server
extrem gut skalierbar ist, von der simplen lokalen Anwendung als Embedded oder als 4*Quad Core Opteron
(also 16 Kerne) unter Linux, so wie Björn das bei der Uni Erlangen demnächst testen will.

Der Firebird Funktionsumfang ist auch allen Ebenen identisch und eine DB kann via Backup/Restore
von jeder Plattform auf jede andere übertragen werden. Viele haben sich bei anderen Datenbanken
von der Volltextsuche oft mehr versprochen (sofortige Verfügbarkeit neuer Daten im Index) oder
auch bei der ggf. erforderlichen Replikation (Regelwerk und mitgelieferte Tools sind manchmal
schwer durchschaubar). Und bei den Express Editions ist das oft gar nicht erst dabei.

Wenn du dich auf eine Plattform festlegen willst kann ich dir ziemlich sicher bestätigen das es
Firebird auch in diversen Jahren noch geben wird. Immerhin hatten wir auf der Firebird Konferenz
letzte Woche in Hamburg fast 120 Leute da, davon einige Kernentwickler und sehr viele Inhaber von
Softwarehäusern, die sehr großen Wert auf die weitere Entwicklung von Firebird legen und diese auch
mit Geld nuterstützen, weil es sich eben rechnet.

Gruß

Holger

[juergen]

Hallo zusammen,
mein Fazit zu diesem ausführlichen (und wie ich fand auch lehrreichen) Thema:
- es gibt wie so oft im Leben "menschliche" Vorlieben und sachliche Argumente

Ich werde mich endgültig auf Firebird festlegen. Zunächst einmal dann mit den Zeos Library Komponenten.
Die Summe der Argumente und meine eigenen Vorstellungen (auch von den Kosten her) führten zu dieser Enstcheidung.
Danke an alle für die vielen Infos und dem regen Meinungsaustausch!

[Hansa]

Zitat von juergen:

..Ich werde mich endgültig auf Firebird festlegen. Zunächst einmal dann mit den Zeos Library Komponenten.

Auf eine richtige Entscheidung folgt direkt die nächste falsche. Was soll denn da im Endeffekt dabei rauskommen ?

[hoika]

Hallo,

ZEOS - falsch sehe ich auch so.

Ein Umstieg auf eine anderes System ist sehr schwer.

mit
Query.Fields['Id']

war das glaube ich.

Es gibt kein FieldByName().AsXXX.

Zweiter Schwachpunkt ist das Fehlen von Hard-Commits,
es werden nur SoftCommits (Commit Retaining) unterstützt,
Ein HardCommit geht nur über das Beenden der Verbindung und Neuaufbau.

Letzte Sache (für mich nicht so schlimm, aber für andere schon):
Ein Connection kann nur eine Transaktion bedienen (wie bei der BDE).



Heiko

[mkinzler]

Zitat:

Es gibt kein FieldByName().AsXXX.

Doch kennt Zeos.
Die Sache mit den fehlenden HardCommits und die fehlende Möglichkeit verschiedene Abfragen in verschiedene Transaktionen zu kapseln wiegt hier schwerer.

[hoika]

Hallo,

ah stimmt, das war UIB, wo das nicht ging.


Heiko

[Tyrolean]

Zitat von juergen:

Zunächst einmal dann mit den Zeos Library Komponenten.

Schau dir doch auch mal AnyDAC an, der implementiert gerade FB/IB-Unterstützung. www.da-soft.com

[mkinzler]

Oder IBDAC, FIBplus

[Rolf Rostig]

Hallo,

welche Komponenten nehme ich denn nun (für Firebird)?
Bislang habe ich die eingebauten Interbase-Komponenten von D7 benutzt.
Jetzt habe ich mir die UIB-Komponenten angeschaut. Eine Dokumentation gibt es wohl nicht?!