Firebirdforum.de

Hallo,

um dieses Forum gleich mit dem ersten Thema zu füllen, möchte ich hier mal in die Runde stellen, was euch an Firebird fehlt. Welche Eigenschaften vermisst ihr? Vielleicht sogar in Bezug auf andere Datenbanken?

Gruß
Martin

Da fällt mir nun nicht sehr viel ein, da ich außer den 4 Standardbefehlen (Select, Update, Insert, Delete) so gut wie nichts benutze .
Ggf. folgendes:
- Bei großen Tabellen (> 1 Mio Sätzen) ggf. Parallel-Abfragen (Multi-Threading)
- Verteilte Datenbank mit gemeinsamen Tabellen (Partitioned Tables)

Was ich vermisse, ist (temporäre) Tabellen über ein SELECT Konstrukt zu erzeugen, entweder via CREATE (GLOBAL TEMPORARY) TABLE AS SELECT... oder aber SELECT .. INTO .. FROM ...

Select into ... from .... gibt es in der original SQL-Standard-Version per

insert into tablea
select * from tableb

Die "Select Into"-Version ist da schon Microsoft-spezifisch.

Ein "Create Table NewTable as Select ...." wäre das eine oder andere mal schon nützlich.
Im Moment behelfe ich mir damit, einen "Select top 1 ..." abzufragen und aus dem Ergebnis dann selber einen Create Table zu basteln.
Anschließend kann ich per obigem "Insert ... Select ..." die Daten dann kopieren.

Vom Microsoft SQL Server habe ich gar keine Ahnung.

Aber mit dem Advantage Database Server kann man schon "ewig" mittels SELECT INTO eine neue Tabelle anlegen aus der Selektion. Schreibt man vor den Tabellennamen ein "#", dann ists eine temporäre Tabelle.
Damit lassen sich komplexe Selektionen realisieren ohne auf prozeduralen Code zurückgreifen zu müssen, denn SPs profitieren leider gar nicht vom Optimizer.

select ... into <table> (oder create table as select ...) gibt es in anderen DBs teilweise seit Ewigkeiten, zb in informix oder MySQL. In Firebird-Terminologie local temporary tables, die fehlen wirklich seit langem. Es gibt bei Firebird zwar global temporary tables (GTT), aber der große Unterschied zwischen den beiden ist, dass bei LTT auch die Struktur der Zieltabelle dynamisch ist. Die kennt man nur häufig nicht, speziell in Systemen, die SQL generieren wie etwa Reporting-Anwendungen.

Und die Struktur, die ein select erzeugt, lässt sich nicht von innerhalb einer Firebird-Datenbank ermitteln, nur über die fbclient von außen, durch ein prepare des statements und anschließende Analyse des Rückgabeobjekts. Damit kann man dann ein create table oder create global temporary table erzeugen und dann erst mit insert into <neue tabelle> select ... füllen. Das ist schon recht umständlich.

Ein weiterer Aspekt bei den GTTs ist die Sichtbarkeit, sie sind user- (bzw connection-) oder sogar transaktionsspezifisch. Mit ersteren lassen sich sehr schön temporäre Daten kapseln, die in einer Session einem User zugeordnet sind.

SPs nutzen übrigens natürlich auch Indizes und den Optimizer, einfach mal den Plan anschauen.

Was mir noch fehlt:
- performanter Import von Massendaten
- ein frei verfügbares DBA-Tool, das die aktuelle Firebirdversion abdeckt
- Dokumentation des neuen Firebird 3 OO-APIs mit mehr Delphi-Codebeispielen
- Dokumentation im Netz wie bei php oder MySQL, inkl aktuelle Version und mit Userkommentaren
- ein nativer php-Firebird-Treiber, der gut gepflegt und dokumentiert ist
- mehr Aktive

Ich halte Firebird weiterhin für das beste Datenbanksystem weit und breit, bzgl Zuverlässigkeit, Leistungsfähigkeit, Basiskonzepten, Standardkonformität, Sprach- und Funktionsumfang, Ressourcengenügsamkeit einerseits und Betriebskosten und Wartungsaufwand andereseits. Besser als Oracle, MS SQL, MySQL, SQLite und Postgres.

Aber beim Ökosystem drumherum und bei der Geschwindigkeit der Weiterentwicklung hängt es leider ein wenig. Das hat einfach damit zu tun, dass es bei Firebird nur wenig manpower gibt - es steht kein großer Konzern dahinter, sondern nur die Stiftung. Firebird ist nicht mehr der Hype wie in der Anfangszeit oder vor Jahren MySQL. Bspw Flamerobin oder der php-Treiber hängen an ein, zwei Leuten, das ist eigentlich kein Zustand.

Darum bin ich bspw froh, dass es wieder ein deutschsprachiges Firebirdforum gibt.

Grüße, Volker

Bleibt abzuwarten, ob das Forum auch mal lebt .
Bisher ist das ja nicht so der Fall.

Was die Möglichkeiten und vor allem die Stabilität angeht, so hat ein Kunde von mir sein DMS nun auf Firebird umgestellt bzw. ist da dran, und hat bisher als Ergebnis, dass die FB z.T. 100x schneller als der SQL-Server ist.
Vor allem beim Insert wird Microsoft da wohl so ziemlich abgeschlagen.

Create Table myTable as (select ...) with Data

kenne und nutze ich natüürlich in der DB400 (AS/400, iSeries).

Die GTT's sind zwar ganz nett, helfen mir bei der BI-Performance allerdings nicht.
Ich zerlege einen komplexen Join in einzelne SQL's mit eigenem "Create Table...;Insert ...Select...;" über mehrere parallele Verbindungen (bis zu 8) um dann bei diesen temporären Tabellen mit Index dann einen Join des Gesamtergebnisses zu erhalten.
Dies ist sauschnell und mit GTT's nicht zu realisieren, da ich dann keine Parallelquery's habe.
Ein komplexer Join, auch mit CTE's, nutzt ja keine echten Zwischentabellen und erzeugt u.U. Millionen von Zugriffen.

In dem Zusammenhang, was könnte fehlen?
Zur Zeit bin ich auf Vermutungen bzgl. der Indexstrategie angewiesen (die FB-Sourcen zu analysieren habe ichda aufgegeben) und erstelle halt diverse Indizes nach meinen Erfahrungen.
Der IBExpert (letzte PE) wirft mir bzgl. der Indexverwendung eine relativ hohe Trefferquote aus.
Schöner wäre es, wenn die FB Index-Vorschläge errechnen und ausweisen könnte, die dann auch effektiv genutzt werden.
Dazu gehört u.U. auchschon mal das automatische Updaten der Selectivity. Dies muss ich nach Masseninserts immer wieder selber machen, da die Indizes sonst nicht genutzt werden.

Dabei fällt mir auch ein:
30 oder auch mehr Indizes sind für die Abfrage ja kein Problem.
Beim Insert fallen sie allerdings mächtig ins Gewicht.
Im Gegensatz zu anderen DB's kennt die FB allerdings das inaktivieren und reaktivieren von Indizes. Beim SQL-Server gibts da nur den Drop und Create, wo ich dann vorher auch noch die Struktur zur Wiederherstellung abfragen muss.

Performancemäßig bin ich hoch zufrieden!

Bis zu 12.000 Inserts in Summe pro Sekunde bei bis zu 4 parallelen Loadern, da sind die Datenquellen bei der Bereitstellung schon häufig langsamer!
Aggregierung von 10Mio Zeilen in ca. 1 Minute (ist je nach Hardware steigerungsfähig).
Backup/Restore zur Normierung von 40GB in ca. 1,5 Stunden.

Und: das Ganze kostenlos

vr2 hat geschrieben: ↑Mo 31. Dez 2018, 01:37 Aber beim Ökosystem drumherum und bei der Geschwindigkeit der Weiterentwicklung hängt es leider ein wenig. Das hat einfach damit zu tun, dass es bei Firebird nur wenig manpower gibt - es steht kein großer Konzern dahinter, sondern nur die Stiftung. Firebird ist nicht mehr der Hype wie in der Anfangszeit oder vor Jahren MySQL. Bspw Flamerobin oder der php-Treiber hängen an ein, zwei Leuten, das ist eigentlich kein Zustand.

Vielleicht gibt es demnächst wieder etwas mehr "Hype", da LibreOffice Base in Version 6 von HSQLDB nach Firebird umgestellt wird. Ist zur Zeit noch "experimentell", aber sie sind dabei...

Soweit ich weiß, wurde das "experimentell" aus LibreOffice entfernt, also als stabil gekennzeichnet.

Was mir in den letzten Jahren aufgefallen ist: Firebird-DBs findet man in vielfältigen Programmen. Leider machen die Hersteller hiermit ihr Geld (was auch legitim ist), unterstützen die Community und die Weiterentwicklung jedoch mit keinem Cent. Gleichzeitig fehlt teilweise das Wissen um die Funktionsweise und Möglichkeiten der Datenbanksysteme.
Das ist natürlich ein umfangreiches und abendfüllendes Thema, das wir eventuell in einem anderen Thread behandeln sollten.

Vor einigen Wochen bin ich über die Entwickler-Mailingliste auf eine Vergleichstabelle verschiedener Datenbanksysteme gestoßen. Vielleicht hilft es dem einen oder anderen:
http://www.sql-workbench.eu/dbms_comparison.html

Gruß
Martin

zu Firebird Wünschen

Hmmm, an sich wünsch ich mir nichts neues, eher das es nicht überladen wird sondern übersichtlich und vor allem stabil bleibt.
Das alleraller beste für mich an FB ist, das man es an sich nicht bemerkt. Und wenn ich dafür ein paar Funktionen weniger hab , was man i.d.R irgendwie umgehen kann, ist das für mich ok.
Ich hab jetzt die Umstellung von 1.5 nach 3.x fast durch, mir reichts erstmal mit neuen Funktionen und neuen Regeln

zum Forum
Yepp, ich finde es auch super, das es wieder ein deutschsprachiges Forum gibt. Das Entwicklerforum glänzte ja zum Schluss mit Antwortzeiten im Bereich von Wochen.
Und ob es überlebt ... liegt ja an uns, an der Besuchsfrequenz, am Umgangston usw.