Nicht alle Artikel sind auf Deutsch verfügbar.
2020-09-10 Blaze-Persistence: Java & SQL gemeinsam noch Stärker
Gastbeitrag
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.
2020-05-04 Java & SQL – gemeinsam Stärker
Letzte Woche habe ich meinen neuen Vortrag „Java & SQL – gemeinsam Stärker“ als kostenloses Webinar auf Englisch präsentiert.
2019-11-13 Mein Interview in „The Art of PostgreSQL“
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.
2019-10-30 Neues in Oracle-Datenbank Version 19c
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.
2019-02-14 Neues in PostgreSQL 11
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.
2019-01-15 SQLite in 2018
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.
2018-11-20 Neues in der Oracle-Datenbank 18c
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.
2018-08-22 Neues in MariaDB 10.3
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.
2018-06-05 PostgreSQL Standard SQL Gap Analyse
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].
Als Kostprobe liste ich die erwähnten Funktionen hier mir kurzen Kommentaren auf. In den Folien finden sich weitere Hintergründe und Charts, die zeigen welche Datenbanken diese Funktionen unterstützen.
2018-04-25 Ein gigantischer Sprung für SQL: MySQL 8.0 veröffentlicht
„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.
Vorsatz
Zu SQL-Datenbanken nicht relationale Datenbank sagen. SQL ist wirklich mehr als nur relational.
Schade nur, dass viele Entwickler SQL noch immer wie vor 25 Jahren benutzen. Ich glaube, das liegt hauptsächlich am mangelnden Know-how und Interesse der Entwickler und an der schwachen Unterstützung in den Datenbankprodukten.
Lass uns dieses Argument mit Blick auf MySQL betrachten. Wenn ich mir den Marktanteil ansehe, glaube ich, dass MySQL’s Mangel an modernem SQL mehr als nur seinen gerechten Teil zu dieser traurigen Situation beigetragen hat. Dieses Problem habe ich 2013 in meinem Artikel „MySQL is as bad for SQL as MongoDB is to NoSQL“ anklingen lassen. Die Schlüsselaussage ist dass „MongoDB ein populärer, aber schlechter Vertreter seiner Art ist – genau wie MySQL für SQL“. Joe Celko hat seine Meinung über MySQL anders ausgedrückt: „MySQL ist nicht SQL, es leiht sich lediglich die Schlüsselworte von SQL aus“.
Beispiele für die fragwürdige Auslegung von SQL gibt es im MySQL WAT-Vortrag auf YouTube [Englisch]. Beachte, dass dieses Video von 2012 ist und sich auf MySQL 5.5 bezieht (die aktuelle Version zu dieser Zeit). Seit damals hat sich die Situation durch die Versionen 5.6 und 5.7 deutlich gebessert.
Besonders erfreulich ist, dass bei der Einführung der neuen Standardwerte einen Schritt weiter gedacht wurde, um die Auswirkungen geänderter Standardeinstellungen möglichst gering zu halten. Als zum Beispiel ONLY_FULL_GROUP_BY standardmäßig aktiviert wurde, hat man sich die Mühe gemacht, die vielleicht vollständigste Prüfung funktionaler Abhängigkeiten mitzuliefern.
- Nicht bei Joins auf Primärschlüssel oder Unique-Constraints
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.
2018-02-05 Modernes SQL: Wie PostgreSQL die Konkurrenz aussticht
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).
2017-06-15 Was ist neu in SQL:2016
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.
- In der
from-Klausel - Einige Funktionen sind „zufällig“ konform
- Weitgehend
- Keine
on overflow-Klausel • Beschränktesdistinct
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…
