Ein Foren-Kommentar aus Frankreich
Verfasst: Do 18. Nov 2021, 19:25
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
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