Was fehlt euch in Firebird?

[vr2]

Hallo LitBigMan,

Bei Interbase kann man beim Erstellen der Datenbank gleichzeitig den Alias anlegen lassen. Dieser kann auch per SQL dann nachträglich angelegt, geändert und gelöscht werden. Das würde bei der Kundeninstallation schon einiges erleichtern.

Aliase waren zumindest mal dafür gedacht, vom physischen Ort einer DB zu abstrahieren, ein Sicherheitsfeature. Jemand, der sich zu einer DB connecten kann, hat noch lange nicht physischen Zugriff auf die DB im Filesystem. Deshalb die Unterbringung in aliases.conf bzw databases.conf-file. Die Vergabe von Aliasen ist natürlich dann über SQL oder API sinnvoll, wenn ihr im laufenden Betrieb häufig Aliase anlegen/ändern müsst, zb weil ihr DBs ständig dynamisch erzeugt und wegwerft.

Grüße, Volker

[vr2]

Hallo Gerd,

... Siehe auch http://www.firebirdfaq.org/faq209/. Ich hoffe das hilft.

Ja, das hilft natürlich.

csv-Import über externe Tabellen ist ein Kompromiss und mühsam, weil es Festformat-csv voraussetzt, und das hast Du eher selten oder musst es erst sicherstellen. csv-Import läuft eigentlich immer darauf hinaus, dass irgendeine Ebene das csv ansaugt, passend zerlegt und in eine Tabelle der DB einfügt. Dabei gibt es allerdings viele verschiedene Szenarien und Problemzonen. Der Ansatz mit den externen Tabellen ist zumindest konzeptionell modular, da man sich nicht frühzeitig auf Datentypen festlegen muss.

Problemzonen sind
* Längenbeschränkungen - Deine csv-Zeilen können nahezu beliebig lang werden, die externe Tabelle kann nicht beliebig lange Sätze aufnehmen. Spalten analog.
* Blobs
* Import beliebig strukturierter csv-Daten - die Zieltabelle muss schon passend existieren - oder Du macht einen Kompromiss und nimmst bspw eine Tabelle mit 80 Spalten a varchar(800) oder einer Spalte varchar(32K) grundsätzlich als Ziel, kann auch eine GTT sein, und zerlegst/verteilst von da aus weiter. Hast Du die Daten mal in der DB, ist der Rest nicht mehr schwer.

Ab Firebird 3 wären UDRs eine Alternative, da Du damit Zugriff auf Filesystem *und* DB haben kannst, aber die sind ziemlich low-level und mager dokumentiert, öffnen Dir allerdings Tür und Tor. Du könntest Dir dann in C++ oder Delphi eine generische UDR für den csv-Import schreiben, die die Zieltabelle entlang der csv-Struktur anlegt. Wenn Du C++ kannst, wär das eine Option, Wenn Du Delphi kannst, kommt es drauf an, denn die UDR-Doku und Ressourcen beziehen sich leider fast ausschließlich auf C++ - außer Du bist gut in beidem und kannst C++-Templates und Makros lesen und auf Delphi abbilden. Ich habe einige UDRs geschrieben, aber für sportlichere Sachen wie BLOBs in UDRs ist die Doku für Delphi einfach zu dünn.

Ansonsten kannst Du natürlich jede Client-Ebene einsetzen, die Zugriff auf Filesystem *und* DB hat und ein prepared statement absetzen kann, Webserver, Desktopanwendung.

Ein Bordmittel wie https://mariadb.com/kb/en/load_file/ wäre natürlich cool und man hätte nicht diesen ganzen Aufriss, dafür brauchst Du aber höhere Rechte, und das Verhalten bei Replikation ist auch nicht unproblematisch.

Grüße, Volker

[bfuerchau]

Auch ein "indexadvisor" für SQL's wäre nicht schlecht, so dass man daraufhin Indizes erstellen könnte, die der Server dann auch nimmt.
Bisher erstelle ich nur nach meiner eigenen automatisierten Methodik Indizes, die nach Analyse mit IBExpert, .Net-Provider zu 95% auch genommen werden.
Eine 100%ige Trefferquote wäre mir da schon lieber.

[Gerd]

@volker Ich melde mich in ein paar Tagen zu Deinem Beitrag. Geht gerade nicht. Tablet tu ich mir nicht an.

Viele Grüße
Gerd

[bfuerchau]

Schon mal angesehen?
https://de.talend.com/products/talend-open-studio/

Lesen fremder DB's, import in beliebige DB's, Konvertierungen, Abläufe, Regeln und automatisierbar.
Warum immer das Rad neu erfinden. Einer meiner Kunden ist höchst zufrieden (von dem habe ich den Hinweis).

[Gerd]

Hallo Volker und bfuerchau.

..."csv-Import über externe Tabellen ist ein Kompromiss und mühsam,"...

Soweit ja. Dennoch, es ist hauseigen. Und ich benutze es dann, wenn es die Aufgabe(n) löst.

Der von @martin.koeditz angeführte Link http://www.firebirdfaq.org/faq209/ verweist ja auf "The Firebird FAQ".

Die dortige Frage (dt. etwa): ..."Gibt es Bulk-Load oder eine andere Möglichkeit, viele Daten schnell zu importieren?"...

Die dortige Antwort dt. etwa): ..."Das Hauptproblem bei externen Tabellen ist die Behandlung von NULLs und BLOBs. Wenn Sie damit umgehen müssen, sollten Sie besser ein Werkzeug wie FBExport verwenden." ...
(Anmerkung: Das genannte Tool würde sich auch für Import-Aufgaben eignen.)

Und da bin ich bei @bfuerchau angelangt - und sehe das so wie er:

... Warum immer das Rad neu erfinden. ...

Genau.
Ich arbeite hier mit einem Firebird Sponsoren Tool und bin bisher damit zufrieden. Das ließe sich dann auch einfach weiterempfehlen ...

Ein Bordmittel wie https://mariadb.com/kb/en/load_file/ wäre natürlich cool und man hätte nicht diesen ganzen Aufriss, ...

Das 'Bordmittel' LOAD_FILE(bezeichner_datei) - mitgeliefert im DBMS MySQL / MariaDB - kenne ich.
Müsste man mal prüfen, ob das schon im Firebird RDBMS Issue Tracker als Feature-Wunsch erfasst wurde. Ich kann dem leider zurzeit nicht weiter nachgehen, weil dort (Firebird Issue Tracker) seltsamerweise mein Login nicht mehr funktioniert - keine Ahnung warum.

... Ab Firebird 3 wären UDRs eine Alternative, da Du damit Zugriff auf Filesystem *und* DB haben kannst, aber die sind ziemlich low-level und mager dokumentiert, ...

Mit dem Thema UDR (User Defined Routines dt.: Nutzer definierte Routinen) ab Firebird 3 habe ich mich bisher noch nicht auseinander gesetzt.
Ich weiß bisher nur, dass es ein neuer Typ von UDFs (User-Defined Functions dt.: Nutzer-definierte Funktionen) sein soll. Dessen Schnittstelle zwischen Firebird und dem eigenen geschriebenen Code soll jedoch etwas anders sein.
Persönlich werde ich mich zu den Schnittstellen-Unterschieden aus Paritätsgründen noch nicht schlau machen können, da UDF ab Firebird v4 standardmäßig deaktiviert ist. Ich nutze ausschließlich Firebird v4 Beta 1 und 2 und ich habe zurzeit nicht vor UDF zu aktivieren.

... Wenn Du C++ kannst, ...

Schön wär's ...

Sobald sich etwas mit Lazarus bewerkstelligen lässt, könnte ich versuchen es damit tun.
Jedoch überlege ich mir immer, ob Aufwand und Nutzen im Verhältnis stehen und/oder, ob es eine fertige Lösung gibt.

Delphi benutze ich nicht. Es ist für mich einfach zu preis-intensiv. Auch würde ich damit vieles erwerben, was ich wohl nie brauchen werde.


Viele Grüße
Gerd

[Gerd]

Das 'Bordmittel' LOAD_FILE(bezeichner_datei) - mitgeliefert im DBMS MySQL / MariaDB - kenne ich.
Müsste man mal prüfen, ob das schon im Firebird RDBMS Issue Tracker als Feature-Wunsch erfasst wurde. Ich kann dem leider zurzeit nicht weiter nachgehen, weil dort (Firebird Issue Tracker) seltsamerweise mein Login nicht mehr funktioniert - keine Ahnung warum.

Hatte den letzten - leider vergeblichen - Login-Versuch am 04.06.2020.
Gerade eben mal wieder versucht - und ich bin (wieder) drin.

Dort gibt es bereits einen Eintrag (+), der darauf abzielt, auch grafische Tools für Firebird anzubieten. Allerdings ist der Wunsch noch offen.


Viele Grüße
Gerd

[colaflasche]

Ganz dringend fehlt mir eine Volltextsuche.

Features aus dem Interbase, die mir fehlen:
- Column-Based-Encryption
- Change Views

Ansonsten wären aktuell wichtige Funktionen für mich:
- Sort-Möglichkeit für List-Funktion
- "Update or insert" aufgrund eines Selects (Wie beim Insert-Befehl), ich weiß, hier gibt es merge, aber das ist deutlich mehr Schreibaufwand
- Bei insert/Update gibt es ja die Returning-Klausel. Wenn die eine Datenmenge mit mehr als einem Datensatz Zurückliefern könnte.

Dann habe ich noch eine Geschichte mit CTEs. Die finde ich total toll, aber unter manchen (vielen) Konstellationen werden die übergeordneten Abfragen dort scheinbar mehrfach ausgeführt, das kann ich mir zumindest an der Ausführungszeit und den Reads herleiten.
Wenn es hier eine Option gäbe, wo man sagen kann, dass die nur einmal ausgeführt werden dürfen und in den folgenden Abfragen dann immer nur die virtuelle Menge selektiert selektiert werden soll.
Aktuell pumpe ich in so fällen eine SQL in eine GTT und selektiere dann die. Den schritt könnte ich mir sparen.

[martin.koeditz]

Hallo colaflasche,

was ist dieses Feature?
- Column-Based-Encryption

Habe eine Vorstellung, aber kannst du das kurz erläutern?

Gruß
Martin

[bfuerchau]

Das Thema CTE ist bei allen DB's ein Problem und ist leider der Standard.
Die CTE ist nur eine erleichterte Schreibweise ohne an der Funktion etwas zu ändern:

select * from TableA A
inner join (select * from TableB where <condition1> ) b1 on ...
inner join (select * from TableB where <condition2> ) b2 on ...

kann vereinfacht werden zu

with B as (select * from TableB ....)

select * from TableA A
inner join B B1 on <Condition1>
inner join B B2 on <Condition2>

Somit erklärt sich eben, dass ein CTE-Ausdruck automatisch keine Tabelle sein kann, da das Ergebnis erst in der Verknüpfung/Verwendung eingeschränkt wird.

Um das zu erreichen, was du möchtest musst du
a) Global Temporary Table verwenden
b) Ein Script erstellen (execute Block, oder halt per Procedure)

Auf diesem Wege kannst du mehrere sessionspezifische Tabellen erstellen, die für jede Verbindung separat existiert. Du kannst schrittweise innerhalb des Scripts selektierte Daten ermitteln und für die Folgeabfrage entsprechend bereitstellen.

Am Bespiel eines SQL-Servers, der das mit den temporären Tabellen einfach per Declare kann) konnte so eine Abfrage von mehreren Minuten auf ca. 300ms reduziert werden.
Man muss halt nur das, was eine Datenbank zur Verfügung stellt, in verschiedenen Ausprägungen kombinieren.
Ich habe für unsere BI-Anwendung z.B. einen "Parallel"-Query gebaut.
Dieser erstellt über mehrere parallele Sitzungen temporäre Tabellen (TEMP-Namen) und füllt diese, um zum Schluss diese Zwischenergebnisse zu einem Gesamtergebnis zu kombinieren. Dabei werden auch dynamisch, also in Abhängigkeit der Abfrage, auch Indizes zur Beschleunigung erstellt.
So arbeite ich seit V2.1 mit der Firebird. Für unsere BI-Anwendung interessieren keine Trigger, Functions, Procedures, die für statische Anwendungen, also z.B. ERP-Systeme, durchaus Sinn machen.

Ach ja: Die TEMP-Tabellen werden natürlich nach Gebrauch wieder entfernt.
Das Create Table und Droptable dauert ca. 15-20 ms, spielt also für die Gesamtdauer der Abfrage keine Rolle.