Es war ungefähr zu dieser Zeit – als MySQL 5.7 herauskam – das ich aufhörte, MySQL zu verspotten. Ich mache natürlich nur Spaß. Natürlich mache ich mich gelegentlich noch über MySQL lustig. Es ist aber schon etwas schwieriger geworden.
Apropos, wusstest du, dass MySQL noch immer keine Check
-Constraints unterstützt? Wie in früheren Versionen kann man bei create table
zwar check
-Klauseln angeben, sie werden aber stillschweigend ignoriert. Ja, stillschweigend: keine Fehlermeldung, keine Warnung. Das hat sogar MariaDB bereits vor einem Jahr behoben. (Update April 2019: MySQL 8.0.16 prüft nun check
-Constraints).
Ach, jetzt mach ich mich schon wieder über MySQL lustig. Entschuldigung, alte Gewohnheit!
Ungeachtet dessen hat sich die Entwicklungsphilosophie von MySQL mit den letzten Versionen spürbar geändert. Was ist geschehen? Du weißt es wohl schon: MySQL steht unter neuer Führung, seit Oracle es mit Sun mitgekauft hat. Und ich muss gestehen: Das war vielleicht das Beste, das SQL den letzten 10 Jahren passiert ist. Und damit meine ich wirklich SQL – nicht MySQL!
Der Grund, warum ich glaube, dass eine einzelne MySQL-Version einen dramatischen Effekt auf das ganze SQL-Ökosystem hat, ist einfach: MySQL ist das schwächste Glied der Kette. Wenn man dieses Glied stärkt, stärkt man die ganze Kette. Lass mich das ausführen.
MySQL ist sehr populär. Laut db-engines.com die zweitbeliebteste SQL-Datenbank überhaupt. Wichtiger noch: die mit großem Abstand beliebteste Gratis-SQL-Datenbank. Diese Popularität hat Auswirkungen auf alle, die sich mit mehr als bloß einer bestimmten SQL-Datenbank befassen. Das sind oft unabhängige Softwarehersteller, die zum Beispiel Redaktionssysteme (CRM), Webshops oder Object/Relationale-Mapper (ORMs) herstellen. Aufgrund der immensen Popularität ist es für diese Hersteller oft notwendig, MySQL zu unterstützten. Nur wenige davon nehmen es auf sich, mehrere Dialekte ordentlich zu unterstützen – Java Object Oriented Querying (jOOQ) sticht hier besonders löblich hervor. Viele Hersteller limitieren sich einfach auf den gemeinsam unterstützten SQL-Dialekt. Also im Wesentlichen auf MySQL.
Eine andere Personengruppe, die von der Omnipräsenz von MySQL betroffen ist, sind Leute, die SQL lernen wollen. Für diese drängt sich MySQL ja gerade zu auf: gratis und beliebt. Das muss doch eine gute Basis zum Lernen sein. Was sie nicht wissen ist, dass sie Ihre SQL-Fähigkeiten damit auf Basis des schwächsten SQL-Dialektes unter den gängigen Datenbanken aufbauen. Frei nach Joe Celko bedeutet das, dass diese Personen die Schlüsselworte zwar kennen, deren Bedeutung aber nicht richtig verstehen. Von modernem SQL haben sie dann natürlich auch noch nichts gehört.
Letzte Woche hat sich das alles geändert als Oracle endlich eine stabile Version (GA) von MySQL 8.0 herausgebracht hat. Diese Version ist ein Meilenstein, da MySQL damit endlich über SQL-92 und das rein relationale Dogma hinauswächst. Neben einiger anderer Standard-SQL-Funktionen unterstützt MySQL jetzt Window-Funktionen (over
) und Common-Table-Expressions (CTE, with
). Ohne jeden Zweifel die beiden wichtigsten SQL-Funktionen seit SQL-92.
Gezählt sind also die Tage, an denen Hersteller behaupten, sie können diese Funktionen nicht, nutzen weil MySQL sie nicht unterstützt. Window-Funktionen und CTEs sind jetzt in der Dokumentation der beliebtesten gratis SQL-Datenbank. Daher möchte ich kühn behaupten: MySQL 8.0 ist ein kleiner Schritt für eine Datenbank, aber ein gigantischer Sprung für SQL.
Und es wird noch besser: Die Zukunft ist ebenfalls rosig! Als MySQL in die Fänge von Oracle geriet, hat ein Teil des MySQL-Teams (unter Ihnen der Gründer) eine eigene Version abgespalten: MariaDB. Wie es scheint ist es die Strategie von MariaDB durch die Einführung viele neuer Funktionen MySQL-Nutzer für das eigene Produkt zu begeistern. Meiner Meinung nach kommt die Qualität dabei zu kurz – wie zuvor bei MySQL – aber das ist eine andere Geschichte. An dieser Stelle ist es wichtiger, dass MariaDB bereits vor einem Jahr begonnen hat Check
-Constraints zu prüfen. Es stellt sich also die Frage: Wie lange kann es sich MySQL noch leisten, Check
-Constraints zu ignorieren? Man könnte auch Fragen, wie lange sie meinen Spott noch ertragen.
Mit MariaDB 10.2 wurde neben Check
-Constraints auch Window-Funktionen und CTEs eingeführt. Zu dieser Zeit hatte MySQL gerade eine Beta-Version mit CTEs, aber noch keine Window-Funktionen. MariaDB bewegt sich also schneller.
Mit Version 10.3 plant MariaDB „System-Versionierte-Tabellen“ einzuführen. In aller kürze: Nachdem diese Funktion für eine Tabelle aktiviert wurde, behält die Datenbank alte Zeilenversionen, wenn mein ein Update
oder Insert
ausführt. Bei Abfragen erhält man natürlich die jeweils letztgültigen Daten, außer man verwendet eine spezielle Syntax (as of
) um nach alten Versionen zu fragen. Mehr dazu in der Ankündigung von MariaDB.
System-Versionierung wurde mit SQL:2011 in den Standard eingeführt. Aktuell sieht es danach aus, als würde MariaDB die erste gratis SQL-Datenbank werden, die diese Funktion unterstützt. Ich hoffe, das das ein Anreiz für andere Hersteller ist und das die Nachfrage nach modernen SQL-Funktionen damit generell steigt.
Jetzt, wo endlich Bewegung in die Umsetzung von modernem SQL kommt, bleibt nur noch ein Problem: die Details! Die Funktionen des SQL-Standards bestehen häufig aus unzähligen Unterfunktionen. Schon alleine deswegen ist es üblich, nicht alle Aspekte zu unterstützen. Am Beispiel Window-Funktionen bedeutet das, dass es nicht genügt zu sagen, dass eine Datenbank Window-Funktionen unterstützt. Welche Window-Funktionen werden wirklich unterstützt? Welche Rahmeneinheiten (rows
, range
, groups
)? Die Antworten auf diese Fragen unterschieden einen Marketing-Gag von einer mächtigen Funktion.
In meiner Mission Entwicklern modernes SQL besser zugänglich zu machen, teste ich diese Details um die Unterschiede hervorzuheben. Die Ergebnisse sind in Matrizen wie oben dargestellt. Im restlichen Artikel soll es daher darum gehen, die neuen Standard-SQL-Funktionen von MySQL 8.0 mit den Mitbewerbern zu vergleichen. Wie du sehen wirst, wurde mit MySQL 8.0 grundsätzlich gute Arbeit geleistet. Nur die neuen JSON-Funktionen stellen eine Ausnahme dar.
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).
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
Bevor wir uns die neuen Funktionen ansehen, noch ein paar Statistiken: Teil 2 des SQL-Standards hat mit 1732 Seiten um 260 Seiten (~18%) mehr als der Voränger. Es wurden 44 neue optionale Funktionen (+14%) eingeführt. Und diese wären…
Markus verwandelt veraltetes SQL-92-Wissen in solides und zeitgemäßes SQL-Know-how