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 SQL4.
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.
Ich biete SQL Schulungen, Optimierung und Beratung an. Auch der Kauf meines Buches „SQL Performance Explained“ (ab €9,95) unterstützt meine Arbeit an dieser Webseite.
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.5
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.
Es gab SQL vor Window-Funktionen und es gibt SQL nach Window-Funktionen. Window-Funktionen sind ohne Übertreibung ein „Game Changer“. Wenn man sie einmal verstanden hat, weiß man nicht mehr, wie man jemals ohne leben konnte. Häufige Anwendungsfälle wie die besten N-Zeilen pro Gruppe finden, fortlaufende Summen und gleitender Mittelwerte bilden oder das Zusammenfassen aufeinanderfolgender Ereignisse sind nur die Spitze des Eisberges. Window-Funktion sind das wichtigste Werkzeug zur Vermeidung von Self-Joins. Alleine das macht viele SQL-Abfragen kleiner und schneller. Window-Funktionen sind dermaßen mächtig, dass sogar neue SQL-Implementierungen wie der Apache Foundation (Hive, Impala, Spark), NuoDB oder Google BigQuery sie bereits vor Jahren eingeführt haben. Es ist also durchaus angemessen zu sagen: MySQL erscheint etwas spät zu dieser Party.
Die folgende Matrix zeigt, wie gut gängige SQL-Datenbanken die unterschiedlichen Aspekte der Over
-Klausel unterstützen. Wie man sieht, übertrifft MySQL sogar den Funktionsumfang der „weltweit fortschrittlichsten relationalen Open-Source-Datenbank“, wie sich PostgreSQL auf der neuen Homepage selbst beschreibt. PostgreSQL 11 bereitet sich aber darauf vor, die Führungsrolle in diesem Bereich wieder zu übernehmen.
Range
-Rahmen unterstützen keine Datetime
-DatentypenRange
-Rahmen können keine <Distanz>
(nur unbounded
und current row
)Die eigentlichen Window-Funktionen, die von MySQL 8.0 angeboten werden, sind auch fast am aktuellen Stand der Mitbewerber.
DISTINCT
-Aggregate werden nicht unterstütztORDER BY
-Klauselrespect|ignore nulls
Null
-Behandlung: lead(<expr>, 'IGNORE NULLS')
(ein String-Argument)respect|ignore nulls
ignore nulls
Null
-Behandlung: first_value(<expr> IGNORE NULLS)
(kein Komma)Null
-Behandlung: first_value(<expr>, 1, null, 'IGNORE NULLS')
(ein String-Argument)ignore nulls
from last
ignore nulls
• Kein from last
with [recursive]
)Die nächste wichtige Erweiterung in MySQL 8.0 sind die sogenannten Common Table Expressions (CTEs oder die with [recursive]
-Klausel). Wichtige Anwendungsfälle sind das durchwandern von Graphen mit einer einzelnen Abfrage, eine beliebige Anzahl an Zeilen generieren, CSV-Strings in Zeilen wandeln (umgekehrtes listagg
/ group_concat
) oder einfach literarisches SQL.
Auch hier schließt der Erstwurf von MySQL gleich zur Spitze auf.
WITH RECURSIVE query_name AS (SELECT…)
Recursive
• Kein Join
im rekursiven Zeit – verwendet stattdessen einen Komma-Join (,
)Recursive
row_number() over()
verwenden, um Top-N-Filter umzusetzenwith … insert … select
Neben Window-Funktionen und der With
-Klausel hat MySQL 8.0 auch einige andere Standard-Funktionen eingeführt. Im Vergleich zu den vorherigen Beiden sind diese aber eher unspektakulär.
,
) um Attributnamen und Werte zu trennen. Keine on null
-Spezifikation,
) um Attributnamen und Werte zu trennen. Keine on null
-Spezifikation[with|without] unique [keys]
order by
-Klauselorder by
-Klausel • Auch für MySQL 5.7.22json_agg
Plan
-KlauselWITH ROLLUP
-Klausel<derived column list>
als in der TabelleWie man unten sehen kann, treibt Oracle den standardkonformen JSON-Support voran. Aktuell sind die Oracle-Datenbank und MySQL in diesem Bereich führend (nicht vergessen: beide aus dem Hause Oracle). Die Funktionen json_objectagg
und json_arrayagg
wurden sogar auf MySQL 5.7.22 rückportiert. Es ist jedoch auffällig, dass MySQL bei diesen Funktionen nicht die Standard-Syntax umgesetzt hat. Zusätze wie z. B. eine Order-By
-Klausel werden grundsätzlich nicht unterstützt. Json_objectagg
akzeptiert weder die Schlüsselworte key
und value
noch den Doppelpunkt (:
) um die Attributnamen von den Werten zu trennen. Es scheint so, als würde MySQL diese Funktionen als normale Funktionsaufrufe behandeln – nicht entsprechend der Syntax des Standards.
Ich finde es auch interessant, dass json_arrayagg
mit Null
-Werten genauso falsch umgeht wie die Oracle-Datenbank (das Standardverhalten ist absent on null
6). Wenn man dieselbe Abweichung in zwei vermeintlich unabhängigen Produkten sieht ist das immer interessant. In diesem Fall kommen beide vom selben Hersteller – das fügt dem ganzen noch das gewisse Etwas hinzu.
Die beiden letzten Funktionen aus der Auflistung, die Grouping-Funktion (gehört zu rollup) und Spaltennamen in der From-Klausel Lösen sehr spezielle Probleme. Die MySQL 8.0 Umsetzung kann mit anderen Datenbanken mithalten.
Darüber hinaus führt MySQL 8.0 auch Rollen ein. Der Grund, warum diese in der Matrix fehlen, ist einfach: Mein selbst gebautes Werkzeug zur Erstellung dieser Matrizen kann aktuell nicht mehrere Benutzer nebeneinander verwenden. Das heißt, ich kann Zugriffsrechte aktuell nicht testen. Das wird aber auch noch kommen – bleib dran.
Zum Abschluss möchte ich auch noch ein paar Neuerungen erwähnen, die nichts mit dem SQL-Standard zu tun haben.
Eine davon handelt von der Desc
-Angabe bei create index
:
CREATE INDEX … ON … (<column> [ASC|DESC], …)
Die meisten – wenn nicht alle – Datenbanken verwenden beim Anlegen eines Indexes dieselbe Sortierung wie bei der order by
-Klausel. Die Voreinstellung ist also Aufsteigend. Manchmal ist es aber notwendig einzelne Spalten eines Indexes gegenläufig zu sortieren. Dafür verwendet man dann desc
. Die MySQL 5.7 Dokumentation sagt dazu folgendes:
Eine
index_col_name
-Spezifikation kann aufASC
oderDESC
enden. Diese Schlüsselworte sind für künftige Erweiterungen erlaubt, um Indexwerte steigend oder fallend zu speichern. Derzeit werden sie erkannt aber ignoriert; Indexwerte werden immer in steigender Reihenfolge gespeichert.
„Werden erkannt aber ignoriert“. Um genauer zu sein werden sie ohne jegliche Warnung ignoriert. Analog zu Check
-Constraints.
Das ist in MySQL 8.0 behoben. Jetzt gibt es eine Warnung. Keine Panik – nur ein Spaß. Desc
wird nun berücksichtigt.
Natürlich gibt es in MySQL 8.0 unzählige weitere Verbesserungen. Der Artikel „What’s New in MySQL 8.0?“ gibt einen sehr guten Überblick. Ein Vorgeschmack:
Histogramme (Optimizer-Statistiken)
Data dictionary in InnoDB (siehe auch: The end of MyISAM)
Bessere Voreinstellungen (kein latin1_swedish_ci
mehr!)
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
Ich persönlich folge in dieser Frage dem Argument von Chris Date: „Domains Can Conatain Anything!“ [„Date on Database: Writings 2000-2006“;ISBN 978-1590597460]. Ein Wert muss nicht mehr „atomar“ sein.
Ich fürchte, dass viele Entwickler es bevorzugen mit der neusten und umjubelten Technologie eines Internetgiganten spielen, als etwas mehr über modernes SQL zu lernen.
Tatsächlicher Titel: MySQL vs PostgreSQL - Why you shouldn’t use MySQL.
Wenn man alte Versionen migriert hat ohne die neuen Standardwerte in die Konfiguration zu übernehmen, kann man manche Probleme aus der WAT-Vortrag noch immer haben.
Leider ein wichtigerer Sprung als ein neuer SQL-Standard.
Für die neugierigen: Oracle hat viel Energie auf die Verbesserung der MySQL-Basis verwendet. Ein hervorragender grund sich etwas langsamer zu bewegen.
SQL-2:2016 §10.11 SR5a.