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.
Ein Interview mit Markus Winand
Markus Winand ist der Autor des sehr berühmten Buches „SQL Performance Explained“ und stellt sowohl http://use-the-index-luke.com als auch http://modern-sql.com zur Verfügung. Markus ist ein Meister des SQL-Standards und ein Zauberer im schnellen entwickeln von SQL-Applikationen die solide Laufzeit-Performance haben!
Entwickler sagen oft, dass SQL schwer zu meistern ist. Stimmst du zu? Was sind deine Empfehlungen an Entwickler, um ihre SQL-Fähigkeiten zu verbessern?
Ich glaube, der Grund warum es vielen schwer fällt, SQL zu lernen, ist dass es eine deklarative Sprache ist.
Die meisten haben mit einer imperativen Sprache programmieren gelernt. Dabei bringt man zahlreiche Instruktionen in jene Reihenfolge, bei deren Ausführung das gewünschte Ergebnis zustande kommt. Eine SQL-Anweisung ist anders, weil sie lediglich das Ergebnis definiert. Am offensichtlichsten wird das in der Select-Klausel, in der man die Spalten des Ergebnisses definiert. Die meisten anderen Hauptklauseln definieren welche Zeilen im Ergebnis sein sollten. Es ist wichtig zu verstehen, dass der Autor einer SQL-Anweisung die Datenbank nicht instruiert, wie die Anweisung auszuführen ist. Das muss die Datenbank selbst rausfinden.
Ich glaube also der wichtigste Schritt, um SQL zu meistern, ist es nicht mehr in imperativen Begriffen zu denken. Ein wiederkehrendes Beispiel, das ich oft in der Praxis beobachte, ist wie sich Entwickler vorstellen, dass ein Join funktioniert. Insbesondere welche Indizes helfen könnten die Join-Performance zu verbessern. Dabei wird ständig versucht wissen über Algorithmen auf SQL-Anweisungen anzuwenden – allerdings ohne zu wissen, welchen Algorithmus die Datenbank überhaupt nutzt. Das verursacht viele Probleme, Verwirrung und Frustration.
Zuerst sollte man sich drauf konzentrieren, eine klare Anweisung zu verfassen, die genau beschreibt wie die Spalten und Zeilen des Ergebnisses aussehen sollen. Wenn nötig kann man sich um die Performance später kümmern. Dabei braucht man dann etwas Insiderwissen darüber, wie die Datenbank arbeitet.
Was ist deiner Meinung nach der richtige Level von SQL-Know-how, den Entwickler erreichen sollten, um ihren Job richtig zu machen.
Alles zu wissen wäre wohl das Beste, glaube ich ;)
In der Praxis ist aber kaum ein Entwickler einfach nur ein SQL-Entwickler. Die Meisten sind Java, C#, oder was-auch-immer Programmierer, die hier und da SQL verwenden, um mit einer Datenbank zu interagieren. Natürlich müssen nicht alle davon SQL-Experten sein.
Heutzutage läuft programmieren oft darauf hinaus das beste Werkzeug für jedes Problem zu finden. Um diesen Job richtig zu erledigen – wie du so treffend formuliert hast – sollten Entwickler zumindest wissen was eine SQL-Datenbank machen kann. Wenn man sich daran erinnert, dass Aggregierungen (sum, count, ...) auch ohne Gruppierung möglich sind – z. B. für fortlaufende Summen, gleitende Mittelwerte, usw. – ist es einfach die Syntax im Internet zu finden, wenn man sie braucht. Daher würde ich sagen jeder Programmierer – und erst recht jeder Architekt – sollte einen guten Überblick darüber haben, was SQL heutzutage alles kann, um die Fälle zu erkennen, in denen SQL die beste Lösung bietet.
Oft können einige Zielen SQL dutzende Zeilen eines imperativen Programms ersetzen. Meistens ist die SQL-Lösung dann korrekter und sogar schneller. Frei nach einem alten Witz über Shell-Skripte würde ich sagen: „Pass auf oder ich ersetze dein Tageswerk imperativer Programmierung mit einer sehr kleinem SQL-Anweisung.“
Du kennst das Verhalten vieler RDBMS-Systeme und bist es gewohnt mit verschiedenen Datenbanken zu arbeiten. Würdest du in Applikationen portablen SQL-Code verwenden oder eine einzelne Datenbank auswählen und alle Möglichkeiten dieser nutzen, indem du maßgeschneidertes SQL schreibst (für beides: Schema und Abfragen).
Ich strebe zuerst immer nach Standard-SQL. Einfach weil ich Standard-SQL am besten kenne und das Verhalten von Standard-SQL am strengsten definiert ist. Standard-SQL definiert selbst für die obskursten Grenzfälle ein sinnvolles Verhalten. Herstellererweiterungen haben die Tendenz sich nur auf die Hauptanwendung zu konzentrieren. In Grenzfällen könnten sie sich überraschend und inkonsistent verhalten – einfach, weil bei der Umsetzung niemand daran gedacht hat.
Manchmal kann ich ein Problem nicht mit Standard-SQL lösen – zumindest nicht ausreichend elegant und effizient. Meistens liegt das daran, dass die Datenbank, mit der ich gerade arbeite, die benötigte Standard-SQL-Funktion nicht unterstützt. Manchmal bietet der Standard auch einfach keine passende Lösung. In beiden Fällen verwende ich dann ohne zu zögern proprietäre Erweiterungen. Für mich ist das lediglich die persönliche Präferenz der Reihenfolge, in der ich mögliche Lösungen ausprobiere. Standard vs. nicht-standard SQL ist für mich aber keine Einschränkung.
Wenn es um die Vorteile von portablem SQL geht, gibt es ein häufiges Missverständnis. Oft wird argumentiert, dass man Portabilität nicht braucht, weil man ohnehin niemals eine andere Datenbank verwenden wird. Ich stimme diesem Argument in dem Sinne zu, als dass es keinen Sinn macht nach Portabilität zu streben, wenn man die Software momentan nicht mit anderen Datenbanken verwenden will.
Andererseits glaube ich, dass es bei Portabilität nicht nur um den Code geht – es geht auch um die Leute. Ich würde sogar sagen es geht dabei mehr um die Leute, als um den Code. Wenn man bevorzugt Standard-SQL verwendet und nur wenn nötig auf Herstellererweiterungen zurückgreift, ist der Code für andere leichter zu verstehen – insbesondere für Personen, die eine andere Datenbank gewohnt sind. Auf die ganze Industrie gesehen bedeutet dass, dass es beim Einstellen neuer Mitarbeiter weniger Reibungsverluste gibt. Selbst aus der Sicht eines einzelnen Entwicklers gibt es einen großen Vorteil: wenn man es gewohnt ist, Standard-SQL zu schreiben, erhöht man die Chancen, dass das SQL das man schreibt, auf vielen Datenbanken läuft. Dadurch wird man am Arbeitsmarkt wertvoller.
Dennoch gibt es eine große Ausnahme: DDL – also Create-Anweisungen. Dabei strebe nicht einmal ich nach Portabilität. Das wäre sowohl sinnlos, als auch zu einschränkend. Wenn man Tabellen, Views, Indizes und so fort in verschiedenen Datenbanktypen anlegen muss, ist es besser eine Schemadefinition pro Dialekt zu verwalten.
Hinweis in eigener Sache
Ich lebe von SQL-Schulungen, SQL-Tuning und Beratung sowie dem Verkauf meines Buches „SQL Performance Explained“. Mehr auf winand.at.
Wie siehst du PostgreSQL im RDBMS-Angebot?
PostgreSQL ist in einer sehr starken Position. Ich sage immer wieder, dass der Funktionsumfang von PostgreSQL aus dem Blickwinkel der Entwicklung näher an dem kommerzieller Produkte, als an dem anderer open-source Mitbewerber wie MySQL/MariaDB ist.
Bei PostgreSQL mag ich insbesondere, dass es sehr viele Standard-SQL-Funktionen unterstützt. Das sind einfache Dinge wie die voll funktionsfähige Values-Klausel aber auch with [recursive], over, lateral und Arrays.
Bezahlte Links
Wenn man Dimitris Buch über einen Link aus diesem Artikel kauft, bekomme ich von Dimitri eine Umsatzbeteiligung. Hier ist ein solcher Link.
