Firebird 3.0

[hanspeter]

Hallo,
ich nutze die Feiertage um ein älteres Delphi-Projekt, welches auf einer Firebird-Datenbank aufsetzt, zu pflegen.
Dazu habe ich mir den aktuellen Entwicklungsstand von Firebird angesehen und war etwas erschrocken.
Ich meine im Jahr 2011 im Entwickler eine Vorankündigung und einen Aufsatz zu den Features von Firebird 3.0 gelesen zu haben.
Jetzt ist die Entwicklung nicht über das Alpha 1 Stadium hinaus.
Was mich an der Version 3 interessiert, ist die damals erwähnte Möglichkeit externe Proceduren in einer beliebigen Sprache schreiben zu können.
Könnte es sein, dass aus dem Projekt ein bischen die Luft raus ist?

Mit vielen Grüßen
Peter

[tsteinmaurer]

Stimmt. Schleppend. Die Roadmaps haben bis jetzt nie gehalten :roll:, aber frei nach dem Motto, "we ship it, when it is ready", stimmt eigentlich immer die Qualität. Nichts ist ärgerlicher als Data Corruption etc. bei einer so zentralen Komponente wie einem DBMS.

Aus Entwicklungssicht ist Firebird schon SEHR lange kein Open-Source Projekt mehr, weil alle Core-Entwickler bezahlt sind. Aus User-Sicht ist es Freibier. Diese Diskrepanz ist schwierig, sehr schwierig. Jeder, der mit dem Einsatz von Firebird seine eigenen Brötchen verdient, ist herzlich eingeladen nur einen Bruchteil an das Projekt zurückgegeben, damit die Finanzierung der Entwickler auf einer soliden Basis steht. Aber das ist, seitdem es die Firebird Foundation gibt, eine alte Leier, die im Vergleich zu den Download-Statistiken brutal auseinander klafft ...

Firebird 3 Alpha 2 steht kurz vor der Veröffentlichung. Aber von einem Production-Ready V3 Release ist man noch entfernt. Gut, es gibt immer was zu verbessern, aber 2.5.2 ist soweit rock solid. :thumb:

Guten Rutsch an alle Delphi-Praxisianer!

[IBExpert]

Wie heißt das noch so schön: Gras wächst auch nicht schneller, wenn man dran zieht ...

wenn du den daily snapshot herunterlädst hat dieser schon das Alpa2 tag
http://web.firebirdsql.org/download/...uilds/win/3.0/

Von der Featureseite her hätte Firebird 2.1 auch schon Firebird 3.0 heißen können und
Firebird 2.5 hätte 4.0 sehr wohl verdient. Die ursprüngliche Roadmap war aber weniger
von einer Marketing Abteilung definiert, sonst wäre Firebird jetzt auch schon bei Version
10 angekommen.

Bei einigen kommerziellen Produkten ist ja der Versionsnummerwahn mittlerweile Standard,
was aber meistens auch bedeutet, das für ältere Versionen gar kein Support mehr angeboten
wird. Das letzte Firebird Patch für die Version 2.1 kam im März 2013, immerhin 5 Jahre
nach Erscheinen der Firebird 2.1 Version.

Bei einer Datenbank ist aber 100% Zuverlässigkeit wichtiger als alles andere. Ob Features
wie externe Stored Procedures in der eigenen Programmiersprache wirklich vorteilhaft sind
oder am Ende dazu führen, die sehr schnelle Implementation der Stored Procedure Sprache
durch lahme selbstgeschriebene externe Module zu ersetzen, muß jeder selbst entscheiden.
Mit UDFs geht das ja schon seit Jahren auf Funktionsebene und auch da hab ich schon sehr
heftige Performance- und Stabilitätskiller gesehen, weil man sich nicht bewusst war, wie oft
diese Module aufgerufen werden.

Zentrales Feature für FB3 war und ist sicherlich SMP Superserver und das läuft mit dem
Alpha2 Release schon sehr gut, obwohl da nicht jeder jetzt erwarten sollte, das
Datenbankabfragen auf Quadcores 4 mal so schnell laufen. Bei den meisten Singleuser
Tests wird man keinerlei Performancevorteil feststellen und schlecht programmierte SQLs
und miese Datenbankmodelle bleiben genauso langsam wie immer.

Ich bin regelmäßig bei Kunden, deren Software extreme Performanceprobleme hat und deren
Kunden das komplett in den Wahnsinn treibt. Aber die Programmierer werten die Informationen,
die Firebird bietet, um die Ursachen zu erkennen, gar nicht aus, sondern basteln die an deren
Quellcodes seltsame Pseudoperformanceoptimierungen rein, die selten was bringen.

Ich befürchte, das dieser Weg durch externe Module eher noch schlimmer wird, daher sehe
ich aktuell sehr wenig probleme darin, das FB3 noch gar nicht als final existiert. FB25
ist wie Thomas schon sagt stabil und performant und bietet Features, die 90 % aller Anwender
eh nicht benutzen, weil die meistens nicht mal die Release Notes komplett gelesen haben.

[hstreicher]

Böse Anmerkung:

jedem den die Entwicklung von Firebird zu langsam geht kann das durch eine kleine Spende an die Firebird Foundation beschleunigen

Daten über die offizielle Firebird Webseite

[hanspeter]

Danke erst mal für die ausführlichen Antworten.
Das ist sehr interessant und beruhigt mich erst einmal.
Letztendlich ist es mir auch lieber wenn es länger dauert und dafür eine stabile Version vorliegt.
Delphi ist da wohl eher ein Beispiel für das Gegenteil. Beta-Test beim Kunden und zuletzt 2 Versionen pro Jahr.

Bezüglich der Geschwindigkeit und Transactionssteuerung von Stored procedure und Firebird events hatte ich in der Vargangenheit weniger gute Erfahrungen gemacht und diese Lösung wieder zurückgebaut.
Was ich als Lösung anstrebe, ist die gesamte Verarbeitung auf dem Server auszuführen und die Clients abzuspecken.
Auf dem Server soll ein Programm laufen. Diese erhält über stored Procedure eine Aufgabe zugeteilt und legt diese erst mal auf einem Stapel ab.
Die Abarbeitung erfolgt sequentiell. Das Programm kann wie ein Client mit Transactionssteuerung arbeiten und sendet nach der Fertigstellung einer Aufgabe einen Event.
Das hatte ich schon mal mit stored procedure gelöst, dann diesen Weg wieder aufgegeben.
Mit FB 3.0 sollte die Lösung realisierbar sein.


Mit Gruß Peter

[IBExpert]

das machen wir regelmäßig immer so, aber das hängt wenig mit der Implementation zusammen,
schon gar nicht mit Fähigkeiten von FB3.

Beispiel: In unserer Software wird für die Volltextsuche ein Suchindex für alle Datensatze
aufgebaut, die sich nach ganz bestimmten Regeln im Auftragskontext befinden. Außerdem wird
der Deckunsgbeitrag immer dann im Auftrag aktualisiert, wenn einzelne Positionen angelegt,
geändert oder gelöscht werden. Auch dabei wird einiges an Datensätzen durchgerödelt.

Für einfache Aufträge ist das sehr einfach, da macht man das eben on the fly, während man
die Daten eingibt. Bei komplexen Aufträge mit dutzenden Fertigungsaufträge, hunderten
Arbeitsgängen und Materialpositionen wird das schon ziemlich ekelig für den Anwender,
insbesondere wei ihn das selten sofort interessiert.

Wenn das also ein Trigger macht, wird das bei jeder Änderung immer gleich im Kontext des
Anwenders gemacht oder mit anderen Worten: Der Anwender wartet bei jede noch so banalen
Änderung auf alles, was irgendein beteiligter Trigger für wichtig hält.

Wir erstellen daher Trigger, die sobald sich was in den relevanten Daten ändert, den Auftrag
in eine Jobtabelle eintragen, falls der da nicht eh schon drin steht. Bei Löschen eines
Fertigungsauftrags mit 10 Arbeitsgängen würde ien Arbeitsgangbasierender trigger auch 10 mal
ausgeführt werden, auch wenn der Löschvorgang in einer Transaktion ausgeführt wird. Das
sieht man sehr gut in der Trace API.

Mit diesem Insert in die Jobtabelle wird dann auch gleich ein Event ausgelöst, dieses aber
erst beim Commit, also nur ein mal. Auf dem DB Server läuft ein Script mit der ibescript.exe
mit ibec_waitforevent oder eine beliebige exe oder ein sonstiges Programm, das die auf diese
Event reagiert, was auch immer das bedeutet. In der Jobtabelle steht dann zum Beispiel drin
EXECUTE PROCEDURE BRPSEARCHUPDATE(123456);
oder
MeinProgramm.exe P1=123456

Wenn der Befehl erfolgreich abgeschlossen wurde, löscht das Script/die Exe auch gleich den Eintrag
in der Jobtabelle (und kann bei Bedarf dort im Delete Trigger wieder ein Event auslösen, der
deine Client Software veranlasst, den Bildschirm zu aktualisieren, wenn der Anwender nicht in der
Zwischenzeit auf einen anderen Bildschirm umgeschaltet hat.

Ob du auf diesem Wege serverseitig komplexe Datenoperationen als Exe implementierst und in deinem
Client nur den passenden Eintrag für die Jobtabelle implementierst, ist dann nur noch die Frage deiner
Architektur, aber keineswegs abhängig davon, das Firebird in irgendeiner Form deinen Quelltext
oder deine DLL direkt einbinden könnte. Großer Vorteil so einer Vorgehensweise ist dabei auch
die Teamfähigkeit in der Entwicklung. Der Front End kann weiterentwickelt werden, obwohl die
Implementation im Backend ggf noch gar nicht fertig ist oder vielleicht sogar Kundenabhängig
variiert werden kann. Die Implementation via Webfrontend oder für mobile Systeme ist dann auch
ein einfaches, weil der dann auch ggf nur den Eintrag in deine Jobtabelle beherrschen muss.
Ich gehe nicht davon aus, das die Implementation externer Prozesduren in Firebird ohne externe
Client in irgendeiner Weise asynchron laufen werden, weil dann das gesamt Transaktionskonzept
problematisch sein wird.

Nun denn, deine angestrebte Idee lässt sich schon heute umsetzen und wird sicherlich gerade bei
größeren Systemen die Anwender erfreuen, weil die Reaktionszeit der Software im Dialogbetrieb
minimiert werden kann.

[hanspeter]

Hallo Holger,

vielen Dank für das Beispiel.
Es entspricht in etwa der Architektur, welche ich mir vorstelle.
So eine Architektur hat nach meiner Meinung noch einen weiteren Vorteil.
Da sie Input/Output nur in der Datenbank hat, lässt sie sich leichter testen.
Der Test läßt sich besser mit DUnit automatisieren.
Funktionieren Events eigentlich jetzt in Firebird problemlos oder ist hier noch etwas zu beachten?
Ich habe 2006 eine Software unter Livebedingungen im laufenden Betrieb von Event auf polling umstellen müssen.
Die Eventsteuerung funktionierte nach dem Programmstart einige Minuten bis zu einer halben Stunde und setzte dann aus unerklärlichen Gründen aus.
2006 war glaube ich noch FB 1.5. Ich meine gelesen zu haben, das es da Probleme gab und die erst mit FB 2.1 wohl beseitigt wurden?
Ich habe jetzt noch einen Rechner, der mit Windows NT4 läuft. Der hatte mit events masive Probleme. (Ein schweinisch teurer Schriftgenerator für Fernseheinblendungen.)
Im Moment verwende ich allerdings keinen dedizierten Server.
Da das System für eine Veranstaltung aufgebaut und danach wieder abgebaut wird, verwende ich einen Client (immer den am besten beaufsichtigten Rechner) als Server.
Das Netzwerk ist teils temporär verlegtes Kabel, teils aber auch bis zu 700 m WLAN.
Insbesondere im WLAN hatte ich Probleme mit events.

Mit den besten Wünschen für einen guten Rutsch und ein gesundes neues Jahr

Peter

[tsteinmaurer]

Zitat:

Funktionieren Events eigentlich jetzt in Firebird problemlos oder ist hier noch etwas zu beachten?

Mit jedem Firebird Release wurde etwas an den Events gefixt/verbessert. 1.5 hatte da noch so manche Probleme. Mit 2.5.2 sind mir aktuell keine Probleme bekannt. Grundsätzlich muss man halt beachten, dass Per-Default, die Eventkommunikation über einen Random TCP-Port geht, sofern man RemoteAuxPort (oder so ähnlich) in firebird.conf nicht konfiguriert. D.h. hier kann man in Firewall-bedingte Probleme laufen. In früheren Firebird Version konnte das zur Folge haben, dass der komplette Firebird Server nachfolgende Requests blockierte etc.

Wichtig ist auch, dass man client-seitig eine stabile Event-Komponente verwendet. Eine weitere Variable kommt hinzu, wenn client-seitig das Ganze Multi-threaded bzw. als Windows-Service eingesetzt wird. D.h. es muss nicht immer notwendigerweise ein Event-Problem auf der Serverseite durch einen Bug im Firebird Server sein.

[Dumpfbacke]

Hallo Leute,
noch eine Frage zu FB 3.0 von meiner Seite. Es sollte doch bei der Version ein Join über mehrere Datenbanken gehen. Ist dem noch immer so ? Dieses ist das einzigste was mir eigentlich bei FB noch fehlt

Tanja

[tsteinmaurer]

Leider nicht in einem Single-SQL-Statement, sondern via EXECUTE STATEMENT in PSQL. Aber das gibt es schon seit 2.5.