Ein Foren-Kommentar aus Frankreich

[Gerd]

Hallo.

Soll ich oder soll nicht Firebird einsetzen - was spricht dafür und was dagegen.

Zum Glück hat Firebird eine große Gemeinschaft auf der Welt. Die Internet-Suche nach weiterführenden Informationen zu Firebird kann sich für den einzelnen aufgrund der Sprachbarrieren recht zeitaufwändig gestalten. U. a. kommen interessante Informationen von langjährigen Firebird-Anwendern. Oft liegen diese in den jeweils lokalen Sprache vor und laufen so Gefahr vom hastig Suchenden übersehen zu werden.
Ich habe so eine Information im Forum des Entwickler- und IT-Pro-Clubs gefunden, die ich hier gerne teilen möchten.
Übersetzt habe ich das mit dem DeepL-Übersetzer (ein Online-Übersetzungsdienst der Deepl GmbH, Köln). Ich kann keine Verantwortung übernehmen, ob das auch tatsächlich alles korrekt übersetzt ist - hört sich aber für mich schlüssig an.

Im 'Forum des Entwickler- und IT-Pro-Clubs' und unter der Themenüberschrift "Firebird 4.0, die neueste Hauptversion der relationalen Datenbank Firebird, ist verfügbar" kommentierte Christ D am 11.06.2021 21:21 Uhr wie folgt:

*** Zitat Übersetzung Beginn

25 Jahre Erfahrung mit SQL, ich praktiziere Firebird seit der 1. Version und davor Interbase 6.0.

Ich habe DB2 auf MVS, DB2UDB, Oracle, SQL Server, MySQL, Interbase, Firebird und PostGre geübt.

Außer bei sehr großen Datenmengen bevorzuge ich bei weitem Firebird.

Firebird lässt sich in 5 Minuten installieren, eine "spezielle" Konfiguration ist selten erforderlich und wenn doch, ist sie leicht zu bewerkstelligen.
Firebird und Interbase verfügen schon seit sehr langer Zeit über gespeicherte Prozeduren, lange vor MySQL.

In Firebird ist es unmöglich, eine gespeicherte Prozedur zu erstellen, die einen SQL-Fehler enthält (eine fehlende Spalte in einer Tabelle).
Es ist in Firebird unmöglich, versehentlich ein Objekt zu löschen, das von einem anderen Objekt referenziert wird.

Ein Backup ist schnell, eine Wiederherstellung ebenso.

Ich konnte die Leistung der gleichen Software zwischen einer MySQL-Version und einer Firebird-Version mit den gleichen Tabellen und Indizes vergleichen: Firebird gewinnt bis zu großen Mengen, bevor es überholt wird.
Firebird/Interbase ist zu fast 100 % SQL-kompatibel: Es gibt keine Funktionen oder "spezifischen" Codes, die nicht auf ein anderes DBMS übertragbar sind.

Und um dem Ganzen die Krone aufzusetzen, haben wir Anwendungen, die kaskadierende Stored Procedures für Upgrades verwenden, die ursprünglich unter Firebird 1.0 entwickelt wurden.
Die Datenbank wurde nach und nach (heute auf Firebird 3.4) durch eine einfache Sicherung/Rücksicherung migriert und es waren keine Codeänderungen erforderlich!

In 20 Jahren, in denen wir 7/7, H24 Dutzende von Kundendatenbanken unter Firebird betrieben haben, haben wir nie eine Datenmanipulation erlebt!
Und das trotz großer Migrationen (von Betriebssystemen, Betriebssystemversionen, Firebird-Versionen usw.).

Während die Migration von MySQL 5.6 zu den folgenden Versionen die Hölle war. Dass heute eine form sratch-Installation von MySQL und deren Konfiguration nichts Selbstverständliches ist und sich dies fast mit jeder Version ändert. Standardmäßig macht uns eine kleine MySQL-Datenbank einen Prozess, der 1 GB RAM beansprucht (es sei denn, man konfiguriert MySQL fein), während der Prozess auf Firebird zehnmal weniger Speicher belegt!

Und reden wir über die Werkzeuge: MySQL Workbench ist eine wahre Fehlerfabrik, die ohne einen Full-HD-Bildschirm unbrauchbar ist (bei niedriger Auflösung sind wichtige Schaltflächen versteckt). Während Flamerobin oder EMS Firebird die Arbeit ohne Bugs sehr gut erledigen. Schlimmer noch, sie enthalten standardmäßig Werkzeuge, die die Abhängigkeiten von DDL-Objekten anzeigen, was MySQL nicht kann! Man muss eine Abfrage von Hand machen!

Natürlich gibt es DB2 oder Oracle und Embarcadero Rapid SQL, aber das ist eine andere Welt, in der das Eintrittsticket für ein kleines oder mittelständisches Unternehmen nicht billig ist.

Ich kritisiere nur drei Dinge an Firebird:
- Die wenigen verfügbaren internen Funktionen (die durch die Möglichkeit, externe Funktionen in C oder Pascal zu entwickeln, ausgeglichen werden).
- die Schwierigkeiten, die externen Funktionen, die man selbst angepasst hat, zu debuggen.
- die Tatsache, dass die Benutzerdatenbank zentralisiert ist.

*** Zitat Übersetzungs Ende

Übersetzt mit DeepL

Wenn ich dort im Forum registriert wäre, dann bekäme Christ D von mir einen Daumen nach oben.

Hoffe, dass der Beitrag von Nutzen ist ...


Viele Grüße
Gerd

[vr2]

Danke für den Kommentar, vieles richtig, einige Ergänzungen:

- Bzgl frei verfügbarer DB-Admin-SW ist es bei Firebird nicht so prall. Mit Firebird-4-Unterstützung sehe ich im Moment nur flamerobin.
- Für mariaDB/MySQL ist https://www.heidisql.com/ zu empfehlen. Ich hatte den Entwickler mal kontaktiert, Firebird in die unterstützten DBMS aufzunehmen, (HeidiSQL ist in Delphi geschrieben, wäre naheliegend) das wollte er aber nicht.
- "Firebird gewinnt bis zu großen Mengen, bevor es überholt wird." Lässt sich so pauschal überhaupt nicht sagen
- "Die wenigen verfügbaren internen Funktionen" - gerade durch Stored Functions lässt sich das unproblematisch und robust erweitern. Und durch das OOAPI gehen externe Funktionen und Prozeduren im DB-Kontext wie bspw ein Webrequest aus der Datenbank heraus.
- "Debugging externer Funktionen" - bei udfs schwierig, das stimmt, aber die sind deprecated, beim Ersatz Stored Functions kein Problem. Davon abgesehen ist Debugging externer libs grundsätzlich nicht einfach.
- "Benutzerdatenbank zentralisiert" - ab Firebird 3 nicht mehr, sondern pro DB konfigurierbar
- Umstellung von 1.5 bis 3 - so glatt wie er es beschrieben hat, war es teilweise nicht, bspw abh von Zeichenkodierung beim Übergang von 2.1 auf 2.5, Migration der Benutzerkonten oder Weiterbetrieb von legacy-Anwendungen von 2.5 nach 3, Behandlung von Zeitzonen beim Umstieg von Firebird 3 auf 4. Bei mariaDB war der Wechsel von 10.2 nach 10.3 problematisch wegen wesentlich strikterer defaults (die aber vorher wirklich Käse waren, sowas wie automatisches Kürzen von Daten, wenn sie nicht in ein Feld passten), und zwischen 10.1 und 10.5 musste gehörig nachoptimiert werden bei der Systemkonfiguration. Kommt halt sehr darauf an, wie man die DBs genutzt hat.

Grüße, Volker

[Gerd]

Hallo Volker.

- ... Mit Firebird-4-Unterstützung sehe ich im Moment nur flamerobin. ...

Ja, Flamerobin kann man noch in diesem Zusammenhang nennen. Mir würde es allerdings gefallen, wenn es intensiver weiterentwickelt würde. Siehe bspw. hier. Der dortige Zeitstempel verweist auf das Jahr 2014 und inhaltlich geht es um das Erreichen von Flamerobins Version 1.0 - bis heute (19.11.2021) nicht erreicht.

Es findet ja gerade (17.11.2021 - 20.11.2021) der 18. 'FIREBIRD DEVELOPERS DAY' (FDD) statt, der maßgeblich von Carlos H. Cantu organisiert wird.
In einem geplanten abendlichen Vortrag wird am 20.11.2021 Roman Simakov (Red Soft's Leiter für Systeme) über Red Database ... aber auch über "Red Expert sprechen, ein Open-Source-, Multiplattform- und völlig kostenloses Firebird/RedDB-Datenbankverwaltungstool, das unzählige Ressourcen bietet, um die Aufgabe der Verwaltung und Wartung Ihrer Datenbanken zu erleichtern. Ich selbst habe hier RedExpert (aktuell v2021.10) seit einiger Zeit in Verwendung. Sehr nützlich und zuverlässig! Es unterstützt bspw. das automatische Erzeugen eines Entitäten-Beziehungs-Diagramms (ERD). Würde es einen Reportgenerator bekommen, wäre das wie Weihnachten und Ostern auf einmal. Aber es gibt noch mindestens ein weiteres Tool; @bfuerchau hat bspw. SquirrelSQL im Forum erwähnt.

- ... - Für mariaDB/MySQL ist https://www.heidisql.com/ zu empfehlen. Ich hatte den Entwickler mal kontaktiert, Firebird in die unterstützten DBMS aufzunehmen, (HeidiSQL ist in Delphi geschrieben, wäre naheliegend) das wollte er aber nicht. ...

Ja, ich denke auch, HeidiSQL (OpenSource) ist für die genannten Systeme empfehlenswert. Der Autor hat seit einiger Zeit nun auch die Unterstützung für SQLite eingebaut.


Viele Grüße
Gerd

[vr2]

Hallo Gerd,

klar, bei flamerobin ist die letzte Aktualisierung Januar 2021. Aber es unterstützt u.a. Packages, DDL-Trigger und Zeitzonen, und es ist FOSS. An flamerobin stören mich nur die rumfliegenden Fenster aus der Frühzeit der linux-Anwendungen, das wäre in Tabs wesentlich übersichtlicher.

Bei RedExpert stört mich,
- dass es Java ist, brauche sonst keine JRE auf der Kiste. jusched telefonierte früher mal ständig nach Hause, sowas fliegt bei mir gleich wieder runter. Unterstütze Oracle auch nicht über Bande.
- bei einer früheren Version funktionierte bereits das Registrieren eines DB-Alias nicht
- man muss dort mit seinen Daten bezahlen (= sich registrieren). Dann kann ich auch WhatsApp benutzen

ERD und Report Generator interessieren mich in einem DB-Admin-Tool persönlich gar nicht. ERD ist unbrauchbar, sobald man eine nennenswerte Anzahl von Objekten in der DB hat oder komplexere SPs. Das lässt sich visuell einfach nicht sinnvoll abbilden, fehlt mir auch nicht. Eine Anzeige der Dependencies eines Objekts ist dagegen unverzichtbar. Report Generator kann sehr komplex werden und gehört in eine Anwendung. Oder meintest Du DB-Statistik-Reports, die gehören natürlich in ein Admin-Tool, die gibts dort normalerweise auch.

Squirrel ist ein System für alle möglichen DBs, die Besonderheiten von Firebird werden sicher nicht voll unterstützt. Außerdem auch Java.

Grüße, Volker

[Gerd]

Hallo Volker.

... - dass es Java ist, brauche sonst keine JRE auf der Kiste. jusched telefonierte früher mal ständig nach Hause, sowas fliegt bei mir gleich wieder runter. Unterstütze Oracle auch nicht über Bande. ...

So betrachtet wird von mir Red Soft-Software deswegen 'unterstützt', weil sie ('Platinum'?)-Sponsor der Firebird Foundation, aber auch Mitwirkende an der Entwicklung des Firebird-Projekts sein sollen. In diesem Fall stelle ich anders als Du diese 'Bande'-Unterstützung einfach mal hintendran.
Ich bin lediglich ein Anwender, der Red Expert sporadisch nutzt. Ich möchte bei dem Tool auf dem Laufendem bleiben. Ich finde es wird von Update zu Update besser und kann es aus diesen Gründen vertreten, es empfehlen ...
Irgendwo* habe ich gelesen, dass FlameRobin in irgendeiner Art und Weise davon auch etwas partizipiert. War es die gemeinsame Nutzung von Icons oder was anderes - kann mich nicht genau erinnern.
Man bedenke auch, der LEITER für Systeme bei Red Soft hat auf dem FDD (diese Firebird-Veranstaltung soll ja die weltgrößte sein) auch über das Datenbankverwaltungstool Red Expert geredet. Ich meine, dies sagt schon etwas aus - oder.
* Falls ich erneut darauf stoße, ergänze ich das hier.

Das mit dem Nachhausetelefonieren ist auch jetzt noch. Ein Update-Check und in den Einstellungen per Checkbox abstellbar. Bei mir ist er an.

Die Reaktionszeit bezüglich Fehlerbereinigung ist aus meiner Sicht nicht zu beanstanden. Der normale Update-Rhythmus beträgt ca. drei Monate. Für mich geht das in Ordnung und auch die einmalige Registrierung sehe ich entspannt.

... Oder meintest Du DB-Statistik-Reports, die gehören natürlich in ein Admin-Tool, die gibts dort normalerweise auch. ...

Nein, ich meine nicht 'DB-Statistik-Reports'.
Es gibt da bspw. einen recht bekannten und offenbar erfolgreichen Software-Hersteller sein Name fängt mit "N" an. Dieser Hersteller, entwickelt eine Reihe Datenbankverwaltungstools für bekannte RDMS. Anwender können optional einen Report-Generator - oder auch Bericht-Generator genannt - mit dazu erwerben. Eben, weil so ein Programm-Modul 'komplex' ist, aber auch, weil es nicht von jeden benötigt wird. Letztendlich wirkt es sich auch auf den Preis aus.
Ich erwarte nicht wirklich, dass Red Expert in absehbarer Zeit einen solchen Generator optional mitbringt (Open Source). Aber man darf hoffen und träumen.

... ERD ist unbrauchbar, sobald man eine nennenswerte Anzahl von Objekten in der DB hat oder komplexere SPs. ...

Hast ja recht. Nur, wenn ich schnell mal einen Überblick brauche, ist das eine bequeme Art sich an eine fremde Datenbank heranzutasten. Die haben das dort gut umgesetzt und sie bleiben dran es zu verbessern - immer mal wieder.

Was mich bzw. meine Arbeitsweise betrifft, hauptsächlich benutze ich die hauseigenen Firebird-Tools und zum Bearbeiten von irgendwelchen Einstellungsdatei das Terminal - den Nano-Editor.


Viele Grüße
Gerd

[Gerd]

- Für mariaDB/MySQL ist https://www.heidisql.com/ zu empfehlen. Ich hatte den Entwickler mal kontaktiert, Firebird in die unterstützten DBMS aufzunehmen, (HeidiSQL ist in Delphi geschrieben, wäre naheliegend) das wollte er aber nicht.

Grüße, Volker

Hallo Volker.

Ich bin gerade zufällig darauf gestoßen. Es gibt aktuell in HeidiSQL vier hinzugekommene Verbindungstypen:

:: 'Interbase (TCP/IP, experimental)'
:: 'Interbase (Local, experimental)'
:: 'Firebird (TCP/IP, experimental)'
:: 'Firebird (Local, experimental)'

HeidiSQL - Version 11.3.0.6444 (64 Bit) vom 10.03.2022

Der Entwickler (Ansgar Becker) hat sich umentschieden.


Viele Grüße
Gerd

[bfuerchau]

Kompatibilität zu anderen DBMS halte ich eher für ein Gerücht.
Klar, wenn man auf SQL92-Standard bleibt, mag das schon stimmen.
Aber leider kann eben jede DBMS ihr eigenes Süppchen kochen und Erweiterungen einbringen.
Dies sind insbesonders spezielle Funktionen die eben nicht kompatibel sind.
Betrachte ich nur die Definition eines [var]CHAR-Feldes.
Wenn ich bei der Erstellung der DB den UTF8-Zeichensatz angebe, sind alle Felder (wennich nichts angebe) automatisch UNICODE.
Ohne UTF8 sind alle eben dem Zeichensatz entsprechend, oder bei NONE sogar binär.
Erst wenn ich die Codierung angebe kann ich genauer sein.
Und ab da unterscheiden sich die DB's zum Teil gravierend von der Syntax.
Das zur Kompatibilität.

Was die Performance angeht, so ist diese i.d.R. eher mittelmäßig.
Nun muss ich auch dazu sagen, dass wir die FB als Datawarehouse für unsere BI-Anwendung verwenden.
Mit der 2.5 und Classic-Installation ließen sich ähnlich wie bei der 3.0 über 1 Prozess je Sitzung (bei 3.0 1 Thread) relativ gute Ergebnisse erzielen.
Wie bei allen DB's steht und fällt eine Abfrage mit guten Indizes.
Allerdings kann es schon mal passieren, dass mit Index die Abfrage langsamer ist, als ohne Index. Dies sind allerdings eher Abfragen mit Group und Where.

Doch das gravierendste Problem ist der Datendurchsatz von und zur DB.
Mit dem ODBC-Treiber und dem .Net-Treiber erreiche ich da im Schnitt zwischen 6000 - 8000 Zeilen je Sekunde. Das sind bei 1 Mio Sätze dann schon mal knapp 3 Minuten.
Bei parallelen Abfragen über mehrere Verbindungen über Threads oder getrennte Prozesse (z.B. IIS-Web) erhöht sich der Durchsatz nicht.

Und das finde ich schon etwas seltsam.

Beim .Net-Treiber (Sourcen gibt es ja) konnte ich mit kleinen Verbesserungen den Lesedurchsatz auf 12000 - 15000 Zeilen verbessern.

Beim Schreiben (ichhabe berichtet), komme ich i.d.R. auf 2-4000 Inserts / Sekunde. Mit meinem BulkCopy (Mehrere Inserts in einem execute block mit Parametermarkern) kann ich auch schon mal bis 30.000 Inserts /Sekunde erreichen, klar. nur bei schmalen Tabellen (4-6 Felder).

Beim SQL-Server, den ich als Developeredition habe, sehen die Zahlen schon ganz anders aus. Lesegeschwindigkeit ca. 15-20000 Zeilen/Sekunde, bei mehreren Verbindungen parallel auch höhere Geschwindigkeiten.
Bei Inserts ohne SqlBulkLoad kann man schon mal 3-4000 Inserts/Sekunde erreichen.
Ich denke da ist bei der FB noch Luft nach oben. Man könnte z.B. parallele Abfagen mit einem Query einführen, wie es SQL-Server auch schafft.

Ganz anders die DB2, dabei meine ich hier im Besonderen die "DB2 for i", die integrierte DB des ehemaligen Systems AS/400, heute eben IBM i.
Hier erält man Lesegeschwindigkeiten bis 200.000 Zeilen Sekunde.
Wohl gemerkt: Über ODBC-Zugriffe im Gigabit-LAN.
Beim Schreiben kann man da auch ohne Probleme 8-10000 Zeilen/Sekunde erreichen.
Ist man jedoch lokal auf der Maschine, so gehen Lese- und Schreibvorgänge in die Millionen.
Da wird z.B. eine Tabelle mit 65 Mio Zeilen in 1 Minute kopiert.
Aber das ist halt eine andere Welt, weil dort auch die Hardware besser vorbereitet ist (zig Festplatten als 1 logical Unit, Schreibcache mit Notstrompuffer) sowie die DB2 integraler Bestandteil des OS ist.

Auf Windows/Linux sind DBMS eben nur Zusatz und müssen mit den Gegebenheiten zurechtkommen.

Was ansonsten die Gleichheit der DBMS'n angeht, so musste ich leidlich feststellen, dass mit unserem neuesten Produkt (ich habe davon erzählt) alleine für die FB, DB2, SQL-Server und Oracle bestimmte Zugriffe auf Informationen individuell entwickelt werden mussten.
Alleine für den SQL-Server habe ich bereits 3 Zugangsmethoden, die alle 3 unterschiedlicher nicht sein können. Hier hat sich der ODBC-Zugang als der effektivste herausgestellt.

Lange Rede kurzer Sinn:
Da ich als BI-Entwickler in Konkurrenz zu Power BI u.ä. stehe, haben wir es noch nicht bereut vor gut 17 Jahren die FB gewählt zu haben.
Allerdings benötigen wir ausschließlich Tabellen mit Indizes (natürlich) sowie den Feldtypen VARCHAR, Double, Timestamp und für die Identity einen BIGINT.
Keine Trigger, Prozeduren, Funktionen und was es sonst noch alles gibt.
Beim ETL sind jedoch vor allem Transaktionen äußerst wichtig und die Satzverwaltung stellt sich als positiv heraus. Denn während des ETL's sind die alten Daten für Berichte immer noch verfügbar.
Versucht das mal mit einen SQL-Server!
Bei einer Power-BI-Abfrage einer gesamten Tabelle unter Transaktionsbedingung steht das gesamte restliche System wegen eines exclusiven Locks der Tabelle.
Unsere Kunden danken uns dies, weil die Installation der FB in 3 Minuten und unseres BI-Webservers in 5 Minuten erledigt sind.
Auch die teuren Lizenzen eines SQL-Servers in einer Virtualisierung entfallen und die Cloud lassen wir auch noch außen vor.

In diesem Sinne
Weiter so

[martin.koeditz]

Hallo bfuerchau,

sind deine Änderungen zum .NET-Treiber irgendwo einsehbar? Vielleicht kann was für den PHP-Treiber davon ableiten.

Gruß
Martin

[bfuerchau]

Nein, das hatte ich mal geposted, wurde aber nicht übernommen.
Es betraf i.W. nur den FbReader:

Meine Lösung:

Code: Alles auswählen

		public override int GetValues(object[] values)
		{
			CheckState();
			CheckPosition();

			var count = _fields.Count;
			if (values.Length < count)
				throw new ArgumentException("Argument too small to hold values");

			try
			{
				for (var i = 0; i < count; i++)
				{
					values[i] = _row[i].Value;
				}
				return count;
			}
			catch (IscException ex)
			{
				throw new FbException(ex.Message, ex);
			}
		}

Das Original rief n-mal die Funktion GetValue(i) in einer Schleife auf:

Code: Alles auswählen

		public override object GetValue(int i)
		{
			// type coercions for EF
			if (_command.ExpectedColumnTypes != null)
			{
				var type = _command.ExpectedColumnTypes.ElementAtOrDefault(i);
				var nullableUnderlying = Nullable.GetUnderlyingType(type);
				if (nullableUnderlying != null)
				{
					if (IsDBNull(i))
					{
						return null;
					}
					if (nullableUnderlying == typeof(bool))
					{
						return GetBoolean(i);
					}
				}
				if (type == typeof(bool))
				{
					return GetBoolean(i);
				}
			}

			CheckState();
			CheckPosition();
			CheckIndex(i);

			return CheckedGetValue(x => _row[x].Value, i);
		}

		private static T CheckedGetValue<T>(Func<int, T> f, int index)
		{
			try
			{
				return f(index);
			}
			catch (IscException ex)
			{
				throw new FbException(ex.Message, ex);
			}
		}

Mehr war nicht nötig um das Lesen erheblich zu beschleunigen da nicht je Feld die Prüfungen wiederholt werden, die sich ja bei mehreren Spalten im Ergebnis nicht ändern.
Aber leider ist in der aktuellen Version mein Vorschlag nicht übernommen worden.
Aber zugegeben, dies betrifft sowieso nur diejenigen, die sich dis Spalten auf einen Rutsch laden und nicht einzeln die GetValue(i) aufrufen.
Wenn man z.B. die Implementation zum Laden eines Grids ansieht, so wird da tatsächlich eher gas Array geladen und nicht jedes Feld einzeln.

Nun baue ich aber ein BI-Anwendung, wo es nicht unerheblich ist, ob ich 3-4000 Zeilen / Sekunde lesen kann oder eben 9-10.000 Zeilen / Sekunde weil ich einige 100.000 Zeilen insgesamt benötige.
In der Nicht-BI-Welt fällt einem das eher nicht auf.

[bfuerchau]

Noch ein Nachtrag:
Bei größeren Abfragen mit Gruppierungen hat sich herausgestellt, dass man die Sort-Einstellungen (Speicherbereiche) auf 8MB/512MB durchaus hochschrauben kann.
Dies brachte bei mir alleine bereits ca. 20% Geschwindigkeitsvorteil.