Die Search
-Klausel von With Recursive
erzeugt eine Spalte, mit der das Ergebnis entsprechend einer Tiefensuche oder Breitensuche sortiert werden kann.
Die Search
-Klausel folgt unmittelbar auf ein rekursives With
-Element – sogar noch vor der Cycle
-Klausel. Sie legt die primäre Reihenfolge mit den Schlüsselworten Depth First
(Tiefe zuerst) oder Breadth First
(Breite zuerst) fest. In der darauffolgenden, zwingend erforderlichen By
-Klausel wird durch eine Liste von Ausdrücken die Reihenfolge pro Ebene festgelegt. Zuletzt weist die Set
-Klausel der so erzeugten Sequenzspalte einen Namen zu.
Greatest()
, least()
Die SQL-Funktionen Greatest
(größter) und Least
(kleinster) akzeptieren ein oder mehrere✓✗ Argumente und liefern den größten oder kleinsten Wert, wenn keines der Argumente Null
ist✓✗.
SELECT GREATEST(1, 2, 3)
FROM …
Greatest
und Least
sind skalare Funktionen. Anders als die Aggregatfunktionen Min
und Max
betrachten sie jede Zeile einzeln.
Merge
SQLs Merge
führt Insert
-, Update
- oder Delete
-Operationen mittels Wenn-Dann-Regeln durch. Das ist nützlich, um den Inhalt einer Tabelle auf den letzten Stand zu bringen. Anstatt eine Delete
- und eine Update
- und eine Insert
-Anweisung auszuführen, genügt eine einzige Merge
-Anweisung, die alles erledigt. Beinahe alles. Leider gibt es ein Szenario, das durch Standard-SQLs Merge
nicht abgedeckt ist, sodass man erst recht zwei Anweisungen braucht. Aber fangen wir von vorne an …
generated always as (…)
(generierte Spalten)Generierte Spalten, auch bekannt als berechnete Spalten oder virtuelle Spalten, sind Spalten deren Wert automatisch aus anderen Werten derselben Zeile ermittelt wird.
Das folgende Beispiel zeigt eine Tabelle mit zwei Basis-Spalten – das sind nicht generierte Spalten: Net_Preis
und USt_Satz
. Weiters wird die generierte Spalte USt_Betrag
definiert, die den Steuerbetrag berechnet.
Dieser Artikel ist ein Gastbeitrag von Christian Beikov, dem Macher von Blaze-Persistence.
Markus hat kürzlich ein Video veröffentlicht, in dem er über Java & SQL spricht, was zu einer kleinen Diskussion mit mir auf Twitter führte. Die Schlussfolgerung, zu der Markus oft kam, ist, dass man durch die Einschränkungen von JPA für einige der fortgeschritteneren Anwendungsfälle SQL schreiben muss. Ich stimme zu, dass JPA upgedatet werden sollte um mehr der fortgeschritteneren Funktionen von DBMS wie Set-Operationen, CTEs, rekursive CTEs usw. zu unterstützen, aber das wird einige Zeit dauern. Das Hinzufügen solcher Funktionen zu einer JPA-Implementierung wie Hibernate ist ein erster Schritt, aber man muss ein breites Publikum von den Vorteilen überzeugen. Manchmal können sich die Leute nicht vorstellen, wie ein ORM diese fortschrittlicheren DBMS-Konzepte nutzen könnte. Um diese Überzeugungsarbeit zu vermeiden, habe ich mit der Entwicklung von Blaze-Persistence begonnen, einer Query Builder API, die auf Basis von JPA die Unterstützung für diese fortschrittlicheren Konzepte mit dem JPA-Modell implementiert.
Im folgenden Artikel werde ich einige der von Markus entdeckten Probleme und Einschränkungen diskutieren und alternative Lösungen bereitstellen, die mit dem JPA-Modell unter Verwendung von Blaze-Persistence funktionieren.
Letzte Woche habe ich meinen neuen Vortrag „Java & SQL – gemeinsam Stärker“ als kostenloses Webinar auf Englisch präsentiert.
Die (aktualisierten) Folien gibt es als PDF-Download (10MB), das Video ist auch auf Vimeo verfügbar.
In 2017 hat mich Dimitri Fontaine um ein Interview für sein neues Buch gebeten. In der Zwischenzeit gibt es eine zweite Ausgabe unter dem Titel „The Art of PostgreSQL“ (bezahlter Link) — das ist uns ein Anlass, dieses Interview hier zu veröffentlichen.
Das Interview wurde auf Englisch geführt und ist im Original hier zu lesen. Unten folgt meine lose Übersetzung.
Die erste Download-Version der Oracle Datenbank 19c wurde im April 2019 veröffentlicht. Im alten Versionierungsschema wäre diese Version nur eine Patch-Release gewesen, sodass es nicht überrascht, dass der Fokus nicht auf der Einführung neuer Funktionen, sondern auf der Behebung bekannter Probleme lag.
Dennoch gab es einige Erweiterungen im SQL-Dialekt und andere nennenswerte Änderungen.
PostgreSQL 11 erschien vor vier Monaten – meine Begutachtung ist also längst überfällig.
Mit Blick auf den SQL-Standard ist bei PostgreSQL 11 die Over
-Klausel das Hauptthema. Über fast acht Jahre, von 2009 bis 2017, war PostgreSQL die einzige gängige, quelloffene und kostenlose SQL-Datenbank, die Fensterfunktionen (window functions) unterstützt hat. Nur ein Jahr später, im September 2018, hatten alle quelloffenen Konkurrenten aufgeschlossen und sind teilweise an PostgreSQL vorbeigezogen. Die PostgreSQL-Gemeinde war allerdings darauf vorbereitet. PostgreSQL 11 erschien noch 2018 und hat die Führungsposition wiederhergestellt und sogar ausgebaut.
Dieser Artikel erklärt dieses Rennen und geht auch auf weitere Neuerungen in PostgreSQL 11 ein.
SQLite ist eine unterschätzte Datenbank. Manche glauben sogar, SQLite wäre keine „richtige“ Datenbank und nicht für den Produktionsbetrieb geeignet. Tatsächlich ist SQLite eine sehr solide Datenbank, die auch Terabytes an Daten verwalten kann. Lediglich die Netzwerkschicht fehlt.
SQLite ist nämlich „nur“ eine Bibliothek – kein Server. Einerseits scheidet SQLite damit für viele Anwendungen aus, andererseits ist es dadurch für viele andere Anwendungen gerade richtig. Offenbar sind das sogar so viele Anwendungen, das SQLite – laut eigener Angabe – die am öftesten installierte und genutzte Datenbank ist. Das ist vermutlich nur möglich, weil SQLite lizenzfrei ist („public domain“). Wenn man also SQL nutzen möchte, um Daten in einer Datei zu speichern, ist SQLite die erste Wahl.
Der SQL-Dialekt von SQLite braucht den Vergleich auch nicht zu fürchten. Die With
-Klausel wurde in SQLite zum Beispiel vier Jahre früher als in MySQL eingeführt. Zuletzt wurde SQLite um Window-Funktionen erweitert – nur fünf Monate nachdem MySQL Window-Funktionen eingeführt hat.
Dieser Artikel widmet sich den SQL-Erweiterungen, die SQLite im Jahr 2018 erfahren hat. Das sind also die neuen SQL-Funktionen der Versionen 3.22.0 bis 3.26.0.
Im Februar 2018 wurde Release 18c der Oracle-Datenbank für Nutzer der Oracle Cloud und eines Engineered-Systems freigegeben. Es dauerte weitere fünf Monate – bis Juli – bevor es einen Download zur Installation auf eigenen Servern gab. Nach weiteren drei Monaten – im Oktober – wurde dann auch die kostenlose Express Edition (XE) auf Version 18c gehoben. Ich glaube man kann sagen, dass die Oracle-Datenbank 18c jetzt vollständig erschienen ist. Für mich der Anlass, einen Blick aus der Perspektive des SQL-Standards darauf zu werfen.
Beachte, dass die Oracle-Datenbank 18c nur eine „kleine“ Version ist – obwohl die vorherige Version 12.2 genannt wurde. Oracle hat sich lediglich dazu entschieden, fortan die letzten beiden Stellen der Jahreszahl als Versionsnummer zu verwenden.
Ich möchte mit einer Ankündigung beginnen: MariaDB wird auf modern-sql.com fortan als separate Datenbank behandelt.
Der Grund für die Aufnahme in meinen Club der gängigen SQL-Datenbanken ist einfach: Obwohl MariaDB ursprünglich als „Zweig von MySQL, der für Benutzer kompatibel mit der Hauptversion ist,“ beschrieben wurde, haben sich die beiden Produkte in den letzten Jahren merklich auseinander entwickelt. Anfangs haben die Unterschiede vor allem betriebliche Aspekte (inkl. rechtliche Aspekte) betroffen. In den letzten beiden Jahren kam es aber auch bei den SQL-Dialekten zu nennenswerten Unterschieden. Die getrennte Behandlung von MariaDB ist daher unumgänglich geworden.
Weiters steigt die Popularität von MariaDB kontinuierlich an und es scheint, als hätte das MariaDB-Team endlich begonnen den SQL-Standard zur Kenntnis zu nehmen. Eigentlich muss ich sagen, dass sie moderne SQL-Standards zur Kenntnis nehmen – nicht den SQL-92-Standard, der inzwischen sechsfach überholt ist.
MariaDB 10.3 zeigt das auf beeindruckende Weise. Dieser Artikel erklärt das im Detail.
Letzte Woche habe ich auf der PGCon.org in Ottawa einen Vortrag „PostgreSQL Standard SQL Gap Analysis“ gehalten. Falls dir das bekannt vorkommt, verwechselst du es vielleicht mit dem gegenteiligen Vortrag „Modernes SQL: Wie PostgreSQL die Konkurrenz aussticht“, den ich auf der FOSDEM und der PgConf.de gehalten habe.
Der Inhalt der Gap-Analyse:
PostgreSQL supports an impressive number of standard SQL features in an outstanding quality. Yet there remain some cases where other databases exceed PostgreSQL’s capabilities in regard to standard SQL conformance.
This session presents the gaps found during an in-depth comparison of selected standard SQL features among six popular SQL databases. The selected features include, among others, window functions and common tables expressions—both of them were recently introduced to MySQL and MariaDB.
The comparison uses a set of conformance tests I use for my website modern-sql.com. These tests are based on the SQL:2016 standard and attempt to do a rather complete test of the requirements set out in the standard. This includes the correct declared type of expressions as well as the correct SQLSTATE in case of errors (teaser: nobody seems to care about SQLSTATE).
This presentation covers two aspects: (1) features not supported by PostgreSQL but by other databases; (2) features available in PostgreSQL that are less complete or conforming as in other databases.
Du kannst die Folien hier runterladen [PDF; 5MB].
„Verwendest Du noch immer SQL-92“ ist die Eröffnungsfrage meines Modern-SQL-Vortrages. Ein erstaunlich großer Teil des Publikums gesteht dann ganz offen, eine 25 Jahre alte Technologie zu verwenden. Bei der Frage, wer noch Windows 3.1 einsetzt – ebenfalls 1992 erschienen – heben nur ein paar Spaßvögel die Hand.
Natürlich ist dieser Vergleich nicht ganz fair. Dennoch zeigt sich dabei, dass es um das Wissen über neuere SQL-Standards schlecht bestellt ist. Seit SQL-92 gab es nämlich fünf Aktualisierungen. Die derzeitig gültige Fassung ist SQL:2016. Viele Entwickler haben noch nie davon gehört.
Viele Entwickler wissen also nicht, dass SQL seit 1999 nicht mehr auf die relationale Algebra oder das relationale Modell beschränkt ist. SQL:1999 hat nämlich Operationen eingeführt, die keine Entsprechung in der relationalen Algebra haben (with recursive
, lateral
) und Datentypen in den Standard aufgenommen, die die klassische Vorstellung der ersten Normalform brechen (array
).
Seit damals – also seit 19 Jahren – ist es nicht mehr wichtig, ob eine SQL-Funktion der relationalen Idee entspricht. Wichtig ist, das eine Funktion eine wohldefinierte Semantik hat und ein echtes Problem löst. Der akademische Ansatz ist einem Pragmatischem gewichen. Heute bietet SQL für fast alle Datenverarbeitungsprobleme eine praktische Lösung an. Manche entsprechen dem relationalen Gedanken, andere nicht.
Am Freitag habe ich am PgDay vor der FOSDEM in Brüssel den Vortrag „Standard SQL Features Where PostgreSQL Beats its Competitors“ gehalten. Die Folien sind unten.
Eine Variante dieses Vortrages werde ich unter dem Titel „Modernes SQL: Wie PostgreSQL die Konkurrenz aussticht“ auf der „Deutschsprachigen PostgreSQL Konferenz“ in Berlin halten (die Anmeldung ist bereits möglich).
Auf winand.at findest Du eine Übersicht aller Konferenzen, auf denen ich demnächst Vortragen werde. Folien zu anderen Vortägen findest Du hier.
Im Dezember 2016 hat ISO eine neue Version des internationalen SQL-Standards herausgebracht (ISO/IEC 9075:2016). Sie ersetzt die vorherige Version von 2011.
Dieser Artikel gibt einen kurzen Überblick über die neuen SQL Funktionen. Genauer gesagt behandelt dieser Artikel nur die Neuerungen in Teil 2 des Standards (SQL/Foundation) – das ist der Hauptteil des Standards.
Weiters zeigt dieser Artikel die Verfügbarkeit der neuen Funktionen in sechs gängigen Datenbaken. Die entsprechenden Abbildungen – siehe unten – spiegeln jedoch nur die Verfügbarkeit der Funktionen, wie sie der SQL-Standard beschreibt, wieder. Ein X in der Zeile JSON bedeutet also nicht, dass diese Datenbank keine JSON-Unterstützung hat. Es bedeutet lediglich, dass die im Standard beschriebenen Funktionen nicht unterstützt werden. Tatsächlich kann jede der sechs Datenbanken mit JSON umgehen – aber jeder auf andere Weise.
from
-Klauselon overflow
-Klausel • Beschränktes distinct
20 Jahre SQL-Evolution kann man nicht an einem Tag nachholen. Abonniere den Newsletter via E-Mail, Twitter oder RSS, um sukzessive aufzuholen und modern-sql.com am Radar zu behalten.
Markus verwandelt veraltetes SQL-92-Wissen in solides und zeitgemäßes SQL-Know-how