Die Firebird Technical Task Group hat ihre Sitzung beendet, und hat die Roadmap zu Firebird 6 veröffentlicht.
https://firebirdsql.org/en/roadmap-v6/
Das nächste Release von Firebird verspricht viele Verbesserungen, darunter Schema-Unterstützung, Tablespaces, JSON-Fähigkeiten, eine Reihe von fortgeschrittenen SQL-Features, signifikante Upgrades des Cache-Systems, Verbesserungen im Optimizer und viele weitere Features.
Die Veröffentlichung von Firebird 6 ist für das Jahr 2026 geplant.
Möchtet ihr mehr Details erfahren? Nehmt an einem ausführlichen Webinar über die Firebird v6 Roadmap teil, das für den 3. April um 10:00 GMT geplant ist.
Bitte beachten: Der Teilnahmelink zum Webinar wird kurz vor dem Termin über die Firebird Foundation E-Mail-Liste versendet. Abonnieren: https://firebirdfoundation.substack.com/
Firebird 6 Roadmap veröffentlicht
Moderator: martin.koeditz
-
martin.koeditz
- Beiträge: 446
- Registriert: Sa 31. Mär 2018, 14:35
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Sehr spannend, habe die Roadmap schon durchgesehen - und natürlich einige Fragen, wie bspw, ob die Einführung von SQL-Schemas bedeutet, dass zukünftig auch cross-db-joins möglich sind wie in Postgres oder MariaDB, bisher muss man das bei Firebird über SPs oder UDRs machen. Oder wie genau die JSON-Unterstützung aussehen wird.
Zum Teilnahmelink: Die Registrierung für den Newsletter nutzt substack.com (https://de.wikipedia.org/wiki/Substack) und drei weitere US-content-provider (bzw Datenhändler), cloudflareinsights.com, sentry-cdn.com und substackcdn.com. Wird der Teilnahmelink nur über diesen Kanal verteilt, oder könntest Du ihn auch hier im Forum posten? Das würde ich vorziehen, da ich denke, dass es nicht nötig ist, diesen Firmen (und damit einer unbekannten Anzahl weiterer Datenhändler) eine meiner Mailadressen zu geben, nur um an einem Firebird-Webinar teilnehmen zu können.
Zum Teilnahmelink: Die Registrierung für den Newsletter nutzt substack.com (https://de.wikipedia.org/wiki/Substack) und drei weitere US-content-provider (bzw Datenhändler), cloudflareinsights.com, sentry-cdn.com und substackcdn.com. Wird der Teilnahmelink nur über diesen Kanal verteilt, oder könntest Du ihn auch hier im Forum posten? Das würde ich vorziehen, da ich denke, dass es nicht nötig ist, diesen Firmen (und damit einer unbekannten Anzahl weiterer Datenhändler) eine meiner Mailadressen zu geben, nur um an einem Firebird-Webinar teilnehmen zu können.
Schemas sind nur Tabellensammlungen innerhalb einer DB.
Bekannt von DB2 for i, Oracle, SQL-Server. Die Ansprache ist dann eine erweiterte Syntax mit Schema.Tabelle.
Cross-DB-Joins sind schon immer mit Vorsicht zu genießen, da sie die Performance nicht unerheblich beeinträchtigen.
SQL-Server kann das va Linked-Server, IBM i mit Remote-DB's u.s.w.
Da SQL für Massendaten optimiert ist die Indexnutzung von erheblicher Bedeutung. Bei Cross-DB-Joins scheitert diese jedoch häufig, da der Einzelsatzzugriff via Index per Remote-Zugriff sehr langsam wird.
Daher verwende ich dies dann eher Programm intern.
Alternativ kann da schon mal die Verwendung von Global temporary Tables hilfreich sein, wenn ich mir die Daten aus der Fremd-DB vorher dahinein lade um dann zu verjoinen.
Dies gilt auch z.B. für den SQL-Server, der anonsten die komplette Remote-Tabelle herunterlädt, verjoint und was nicht benötigt wird, nach der Abfrage wieder verwirft. Bei einigen 100.000 Zeilen je Tabelle kann man sich ausrechnen, was das so kostet.
Bekannt von DB2 for i, Oracle, SQL-Server. Die Ansprache ist dann eine erweiterte Syntax mit Schema.Tabelle.
Cross-DB-Joins sind schon immer mit Vorsicht zu genießen, da sie die Performance nicht unerheblich beeinträchtigen.
SQL-Server kann das va Linked-Server, IBM i mit Remote-DB's u.s.w.
Da SQL für Massendaten optimiert ist die Indexnutzung von erheblicher Bedeutung. Bei Cross-DB-Joins scheitert diese jedoch häufig, da der Einzelsatzzugriff via Index per Remote-Zugriff sehr langsam wird.
Daher verwende ich dies dann eher Programm intern.
Alternativ kann da schon mal die Verwendung von Global temporary Tables hilfreich sein, wenn ich mir die Daten aus der Fremd-DB vorher dahinein lade um dann zu verjoinen.
Dies gilt auch z.B. für den SQL-Server, der anonsten die komplette Remote-Tabelle herunterlädt, verjoint und was nicht benötigt wird, nach der Abfrage wieder verwirft. Bei einigen 100.000 Zeilen je Tabelle kann man sich ausrechnen, was das so kostet.