Firebird connector für MySQL, ODBC, duckdb

[vr2]

Dann stellt sich mir nur die Frage, warum ein mir bekannter anderer BI-Anbieter von der spaltenorientierten DB auf eine zeilenorientierte DB umsteigt, weil diese beim bereitstellen von Zeilendaten einfach schneller ist?
https://de.wikipedia.org/wiki/Spaltenor ... _Datenbank

Das ist so pauschal einfach nicht zutreffend. Auch bei einer intern spaltenorientierten Struktur kann man schlecht implementieren und den Vorteil der Architektur für OLAP zunichte machen. Zb lässt sich durch die Spaltenorientierung eine Abfrage parallelisieren. Es ist auch nicht so, dass spaltenorientierte RDBMS nur bei einer handvoll Spalten performen, das ist ja keine Schönwetter-Technik. Der wikipedia-Artikel ist außerdem noch in anderer Hinsicht veraltet, denn duckdb wird nicht mal erwähnt, dabei ist es eins der aktivsten und Maßstäbe setzenden Projekte im Bereich OLAP/BI seit einiger Zeit.

Was den BI-Fokus angeht, so benötige ich i.d.R. immer alle Spalten einer Tabelle, da die Aggregierung a) per Code durchgeführt wird und b) die Filterung durch Filter-Elemente sowie Drilldown außerhalb der Db stattfindet, da jede DB-Abfrage eben länger dauert als die Durchführung der Aktion InProcess.

Die Wette würde ich halten, dass das nicht so ist. Besser als Annahmen sind realistische Tests, die man selber durchgeführt hat. Wenn ihr irgendeine Stelle habt, wo es hing bei der Performance, verfütter 4-5 Tabellen à 10 Mio Sätzen und meinetwegen auch 70 Spalten breit per csv an duckdb und lass mal ein paar sportliche Abfragen drauf laufen. Das ist eine Sache von einer Stunde. Brauchst nicht mal Indizes zu definieren. Dann sieht man schnell, ob die Engine was taugt für die Aufgabe oder nicht.

Ich verstehe ja ein gewisses Beharrungsvermögen, wenn man jahrelang bestimmte Werkzeuge nutzt und mit ihnen vertraut ist, passende Konzepte zurechtgelegt hat und erfolgreich zum Ziel kommt. Nur geht da draußen die Entwicklung weiter, und ab und zu gibt es spannende Neuentwicklungen. Ich bin weiterhin großer Firebird-Fan und habe keinen Grund zu wechseln, aber was ich bei duckdb gesehen habe, war beeindruckend, und diese Power und geringe Komplexität möchte ich nutzen können, am liebsten direkt von Firebird aus. Deshalb plugin. Da hier manche im Bereich BI unterwegs sind, wollte ich die Erkenntnisse einfach mal weitergeben - ob man was damit macht, kann ja jeder selbst entscheiden.

duckdb ist top, was Performance, SQL-Funktionsumfang und Schnittstellenvielfalt angeht, aktuell die Messlatte, aber bzgl Orthogonalität, Concurrency und Unterstützung von Stored Procedures/Stored Functions unterirdisch. Deshalb: Kein Ersatz für Firebird (will/kann es als in-process-DB auch nicht sein), aber eine willkommene Ergänzung.

[vr2]

Hi zusammen,

im letzten Jahr hatte ich Tony Whyman von MWA (dem Autor von IBX / fbintf - Delphi/Lazarus/Freepascal-Packages und Connectivity-Libs für Firebird, die aktuellsten, die es gibt, mit vollem Firebird 5-Support), siehe

https://github.com/MWASoftware,
https://github.com/MWASoftware/fbintf
https://www.mwasoftware.co.uk/

wegen der lib-Unterstützung für Firebird provider angeschrieben, hier seine Antwort:

If you want to go down this path, you need first to make sure you have the most recent version of fbintf (1.4.2) then look at the unit in client/3.0/firebird/FirebirdOOAPI.pas and the Readme in the same folder. The doc/Using_OO_API.html file that comes with the Firebird source code also provides some useful info on the basic framework.

Your objective is to write a new so/dll for your provider and to be placed in firebird's lib directory and with an exported entry point "firebird_plugin" declared as

procedure firebird_plugin(master: IMaster); cdecl;

Thinking aloud about what has to be done to create this so/dll:

In order to write a new provider, you will need to subclass the abstract class "IProviderImpl" (FirebirdOOAPI) and register a plugin factory for the new provider with the plugin manager accessed via IMaster. This is relatively straightforward as there are only a few methods to implement.

However, both the create and attach database methods must return an IAttachment interface. This should represent a connection to your database provider. In order to implement this, you must subclass IAttachmentImpl and return the IAttachment pointer from an instance of this class. IAttachmentImpl is much richer with many more methods - although many will return a "not supported" status code if there is no such function provided by your database.

Similarly, you will have to subclass ITransactionImpl, IStatementImpl, IResultSetImpl and so on. You will also need to manage Firebird message buffers. The fbudr interfaces and classes in FBUDRController may help you with the metadata and message buffers - although may need some tweaking.

I am not sure as to how much can be provided in the way of an fbProvider support library similar to fbudr. I am thinking along the lines of:

1. Providing and registering the plugin factory.

2. Support for metadata and message buffer packing/unpacking.

There may be more that can be done, but a concrete example will be needed to work this out. fbudr can certainly provide a model for (1) above and much of (2).

Wenn hier also Delphi/Lazarus/Freepascal-Leute mitlesen, die IBX bzw fbintf und fbudr kennen, das oben beschriebene ist grob, was für als Basis für Firebird provider nötig ist. Die benötigte lib wäre konzeptionell ähnlich wie fbudr, was nur eine kleine Schicht über fbintf ist. Weiterer Input in welcher Form auch immer (Ideen, Schnipsel, Konzepten) ist hier willkommen, alleine schaffe ich das derzeit nicht.

Grüße, Volker

[bfuerchau]

Was willst du eigentlich genau tun?
Habe ich das richtig verstanden, dass die einen Pascal-FBProvider entwickeln willst?

Du könntest doch den originären .Net-Firebirdprovider mittels Wrapper direkt verwenden:
https://sourceforge.net/projects/net-na ... or-pascal/
Somit brauchst du nur einen Wrapper für die Standard DB-Klassen.
Was in meinen Augen erheblich einfacher wäre und du könntest schneller von neuen Versionen des Firebird-Providers profitieren.

[vr2]

Was willst du eigentlich genau tun?
Habe ich das richtig verstanden, dass die einen Pascal-FBProvider entwickeln willst?

Nein, ich möchte in Pascal Firebird-Plugins schreiben können, die direkten Zugriff auf andere Datenbanken von Firebird aus ermöglichen. Sowas wird auch Provider genannt.

Ich möchte in einer Firebird-SP oder einem execute block (weiß noch nicht, ob das auch direkt in einer Firebird-Abfrage möglich ist, eine Tabelle Firebird, eine andere bspw MariaDB) eine andere, nicht-Firebird-Datenbank direkt abfragen (1. Schritt) oder ändern (2. Schritt) können. Zb Postgres oder MariaDB oder irgendwas anderes. Jedenfalls direkt, fast als wäre es eine remote Firebird-DB, nur der connect-String etwas anders. Dass das möglich ist, weiß ich, aber Code, der das leistet, ist nicht öffentlich verfügbar und es werden nur bestimmte DBs unterstützt. Mir geht es aber um eine grundsätzliche Lösung, so dass jeder, der in einer bestimmten Sprache unterwegs ist, in diesem Fall Pascal, solche Provider für seine bevorzugten/benötigten ZielDBs erstellen kann. Wofür hat Firebird sonst diese Schnittstelle, wenn in der ganzen Welt nur 2-3 Leute damit Schnittstellen zu anderen DBs implementieren können? Firebird hat so viele Super-Features, aber hier und da hakt es daran, die PS auch auf die Straße zu bringen.

[bfuerchau]

Wie ich schon mal geschrieben habe, macht das eher wenig Sinn .
Aber wenn man halt genug Zeit hat, kann man das schon machen.
Ich greife für usere ETL-Prozesse immer auf ODBC/OLEDB zurück und musste da schon feststellen, dass die Implementation diverser Treiber trotz aller Definitionsvorschriften nicht einheitlich ist. Das macht die Sache halt eben ineffektiv.

Der aktuelle Batch-Modus der Firebird ist auch eben ineffektiv, da es eben nur um Inserts und keine "Update or Insert" geht. Für ETL ist eben letzteres wichtig und mit dem direkten Scripting "Execute Block" kann man bis zu 255 Insert or Update schreiben sowie bis zu 2000 Parameter-Definitionen verwenden. Mehr geht zwar auch, allerdings wirds dann wieder langsamer.
Auch das Script kann ja bis 10MB groß werden und das reicht wenn man Feldinhalte als Parameter übergibt. Somit bleiben die SQL's eben auch kürzer.

Und wenn man mit dem Batchmodus lädt, wird erst alles in eine Temp-Tabelle geladen um dann einen "insert into .... select * from ..." machen zu können. Bei einer Primary/Unique-Key Tabelle erfährt man dann Keyfehler erst sehr spät.

Ach ja: Der Microsoft-SQL-Server bietet ja auch einen "Verbindungsserver" an, mit dem man ebenso auf ODBC/OLEDB-Tabellen anderer Datenbanken zugreifen kann.
Auch hier ist dann alles erlaubt, was SQL so hergibt.
Die Ergebnisse sind dann alles andere als performant wenn man remote und lokale Tabellen miteinander vermischt.
Hinzu gibts noch Sicherheitsrisiken, da man in der Verbindung ja User und Kennwort für den Zugriff hinterlegen muss. Zwar kann man auch die Verbindungsserver für User im SQL-Server berechtigen. Aber wenn man sowas tut, ist häufig das Einfall-Tor weit offen.

Wie schon ein früherer Mitarbeiter mal sagte:
"Wer zu allen Seiten offen ist, der kann nicht ganz dicht sein!"