Der Anfang
Woher kommt SQL eigentlich? Die Datenbankabfragesprache, die inzwischen viele flüssig “sprechen”, ist schon über 50 Jahre alt. Die beiden Erfinder Donald Chamberlin und Raymond Boyce hatten sich in den 1970er Jahren zum Ziel gesetzt, basierend auf Edgar F. Codds Arbeit zur relationalen Algebra eine Sprache zu entwickeln, die dem ”Gelegenheitsbenutzer“ (casual user) erlauben sollte, eine einfache Abfrage auf Tabellen auszuführen. Diese sollte mit gängigen englischen Wörtern auskommen und keine kryptischen Zeichen verwenden. Das Designziel "ein Benutzer ohne spezielle Ausbildung sollte das Statement beim ersten Lesen verstehen können“ wurde für sehr einfache Fälle sicherlich erreicht, doch aus praktischer Anschauung wissen wir alle, wohin der Weg ab dort führte…
Da SQL auf offenen Standards basierte und nicht durch Patente eingeschränkt war, konnten verschiedene Unternehmen SQL-basierte Produkte entwickeln und damit zur Verbreitung beitragen. Larry Ellison, Gründer von Oracle, war eine der Personen, die das Potenzial erkannten, und – auch durch sein nicht unerhebliches Marketing-Talent – SQL und relationale Datenbanksysteme nach vorne brachten.
Die Standardisierung
Es gibt verschiedene SQL-Dialekte, was dazu führt, dass nicht jedes Statement auf jedem Relational Database Management System (RDBMS) läuft. Um die Interoperabilität möglichst zu gewährleisten, gibt es seit 1986 den SQL-Standard, gegen den die Hersteller ihre jeweiligen Implementierungen prüfen lassen können. Inzwischen gibt es die 9. Version dieses Standards, SQL:2019. Der SQL-Standard wird von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) gepflegt.
Oracle weicht an manchen Stellen von diesen Standards ab. Was einem sicher sofort einfällt, ist der Oracle-typische Outer Join mit dem (+)-Operator. Inzwischen wird der ANSI-Join ebenfalls angeboten und verhält sich in den meisten Fällen auch genau gleich. Beim Full Outer Join muss man ohnehin die ANSI-Schreibweise verwenden.
Ein weiteres kleines Beispiel für eine Abweichung zwischen den SQL-Varianten ist der Umgang mit NULL. Im SQL-Standard ist NULL kein Wert, sondern ein Platzhalter. Überraschend ist für viele User, dass in der Oracle-Datenbank NULL genauso wie ein leerer VARCHAR2 behandelt wird, so dass '' is null den Wert true ergibt und die Verkettung eines Strings mit NULL eben nicht NULL zum Ergebnis hat. Übrigens ist der ||-Operator auch eine Oracle-Spezialität.
Eine Ursache für Abweichungen ist häufig, dass Oracle dem Standard voraus ist, um die speziellen Bedürfnisse seiner Kunden zu befriedigen; die Einbindung in den Standard erfolgt dann später. Auf der anderen Seite gibt es Features im Standard, auf die Oracle-Nutzer sehnlichst warten, wie z. B. separate Datentypen für Datum ohne Uhrzeit und Uhrzeit ohne Datum. Damit könnte man Abfragen vereinfachen und auf Workarounds wie Constraints verzichten.
Von SQL zu PL/SQL
Um mit der neuen Abfragesprache SQL Anwendungen bauen zu können, führte Oracle 1991 die prozedurale Programmiersprache PL/SQL ein. Die Ähnlichkeiten mit Ada oder Pascal sind nicht zufällig; die Sprachen dienten als Grundlage für die Entwicklung. Die Entwicklung von PL/SQL ermöglichte auch die Einführung von Triggern in der Datenbank, die sehr nützlich sind, aber auch gewisse Tücken mit sich bringen.
Für die Frontend-Entwicklung benötigt man wiederum ganz andere Sprachen, aber wenn Performance eine Rolle spielt, sollte so viel Programmlogik wie möglich in SQL, bzw. PL/SQL “verpackt” werden, wie die Erfahrung aus vielen Praxisprojekten zeigt. Es gibt verschiedene Faktoren, die sich negativ auf die Performance auswirken. Dies sind zum einen viele Context Switches, da SQL und PL/SQL von unterschiedlichen Engines bedient werden, und zum anderen die berüchtigte Row-by-row-Verarbeitung. Dass es keine gute Idee ist, Datensätze einzeln aus der Datenbank zu lesen und einzeln auch wieder zurückzuschreiben, ist intuitiv verständlich, aber die PL/SQL unterbindet es auch nicht. Daher ist die Versuchung groß, den einfachen Weg zu gehen. Es lohnt sich aber, sich mit den verschiedenen Möglichkeiten des Bulk Processing zu beschäftigen. Auch kleine Batch-Größen versprechen hier schon große Geschwindigkeitssteigerungen.
Grundsätzlich gilt für SQL wie für PL/SQL: Annahmen sind zu überprüfen. Alte “Daumenregeln” für Indexe, Formulierung von SQL-Statements, Caching-Verhalten etc. müssen in einer neuen Datenbankversion nicht unbedingt weiter Gültigkeit besitzen. Optimizer und Datenbank-Engine können sich anders verhalten als vorher.
Auch gibt es selten Features, die immer zu einer Verbesserung führen. Ein Beispiel ist die Compiler-Direktive PRAGMA UDF, eingeführt mit Oracle 12c, die eine PL/SQL-Funktion beschleunigen soll, wenn sie im Kontext eines SQL-Statements aufgerufen wird. Vor der produktiven Einführung ist zu testen und zu vergleichen, ob hier wirklich der gewünschte Effekt eintritt.
XML und JSON
Mit der zunehmenden Bedeutung von XML und JSON in modernen Anwendungen hat auch SQL entsprechende Erweiterungen erfahren. XML (Extensible Markup Language) und JSON (JavaScript Object Notation) sind Formate zur Darstellung strukturierter Daten, die häufig in Webanwendungen verwendet werden. Die Fähigkeit, XML- und JSON-Daten zu verarbeiten, hat SQL zu einer noch vielseitigeren und leistungsfähigeren Sprache gemacht, die den Anforderungen moderner Anwendungen gerecht wird. In Oracle-Datenbanken gibt es beispielsweise die Möglichkeit, XML-Daten in speziellen XMLType-Spalten zu speichern und mit XPath- und XQuery-Ausdrücken zu durchsuchen. JSON-Daten können in VARCHAR2- oder CLOB-Spalten gespeichert und mit JSONPath-Ausdrücken durchsucht werden. Diese Erweiterungen ermöglichen es, relationale Datenbanken nahtlos in moderne, datengetriebene Anwendungen zu integrieren. Oracle 23ai bietet zum Beispiel JSON Relational Duality Views und JSON Schema Validation, außerdem wurde der JSON-Datentyp besser in SQL integriert.
Die Metadaten
Ein besonders schönes Feature der Oracle-Datenbank sind die unzähligen Metadaten-Views, die einen guten Überblick über die vorhandenen Datenbank-Objekte bieten und sich vielseitig einsetzen lassen. Seit Version 11 ist eine neue Sorte hinzugekommen: Dank PL/Scope lassen sich jetzt auch PL/SQL-Codeeinheiten analysieren. Die entsprechenden Views zeigen die Struktur des Codes, die deklarierten Variablen mit ihren sämtlichen Referenzen und die DQL-/DML-Statements, die im Code verwendet werden. Diese Details gehen weit über das hinaus, was mit den bisherigen Dependencies-Views möglich war, und bieten tolle Möglichkeiten um die Leistung zu überwachen, Sicherheitslücken zu identifizieren und die Datenbankstruktur zu optimieren.
Open Source
Macht man sich auf die Suche nach Open-Source-Projekten in PL/SQL, so findet man nicht viel in den einschlägigen Repositories, verglichen mit den “angesagten” Sprachen. Dafür gibt es einige kleine, sehr gut implementierte Frameworks, zum Beispiel für Logging und Unit Tests, oder auch kleine Helfer-Packages für verschiedene Zwecke. Oftmals liegt das letzte Bearbeitungsdatum lange zurück, einfach weil die Projekte schon sehr ausgereift sind. Weitere Projekte werden natürlich gerne gesehen – und helfen dabei, KIs für zukünftige PL/SQL-Entwicklungen zu trainieren!
Die Tools
Neben den kommerziellen Produkten für die Entwicklungsarbeit mit SQL und PL/SQL gibt es auch eine Reihe Tools, die Oracle im Rahmen der Datenbank mitliefert. Das gute, alte SQL*Plus sollte man kennen, aber auch die frische und aufgepeppte Variante SQLcl, die 2016 der Öffentlichkeit vorgestellt wurde. Dieses Command Line Tool hat viele praktische Features, die über SQL*Plus hinausgehen, und wird ständig erweitert.
Als “große” Entwicklungsumgebung gibt es seit 2005 den SQL Developer. Da das Tool einen gewissen Reifegrad erreicht hat, passiert hier nicht mehr so viel, ganz im Gegensatz zum SQL Developer für VS Code, der Extension für den weitverbreiteten Code-Editor von Microsoft. Hier darf gerne getestet und Feedback an die Entwickler gegeben werden!
Wer sich gar nichts lokal installieren möchte, kann das 2015 veröffentlichte LiveSQL im Netz zurückgreifen. Hier gibt es viele vorgefertigte Beispiele, und man benötigt nicht einmal einen Account, um direkt loslegen zu können – je nach Wunsch im klassischen SCOTT-Schema oder im etwas größeren HR-Schema. Einfacher geht es wirklich nicht!
Exkurs: Partythemen
SQL hilft nicht nur bei der Arbeit, sondern eignet sich auch wunderbar für Smalltalk – da es wahrscheinlich nie zu einer Einigung kommen wird, ob es nun “See-quel” oder “Es-Queue-El” heißen soll (und “Squirrel” ist nun wirklich zu exotisch!), ob ANSI-Joins hässlicher als (+)-Joins sind, warum man keinen Outer Join mit einem (+) auf beiden Seiten deklarieren kann, ob man die Kommata vor oder hinter die Spaltennamen im Select setzen sollte, ob ein einziger NULL-Wert wirklich ausreicht, um mindestens ein Dutzend möglicher Bedeutungen auszudrücken und man wirklich BOOLEAN als Spaltentyp braucht. Ein ebenfalls beliebtes Diskussionsthema ist die Frage, ob sich Venn-Diagramme zur Darstellung von SQL-Joins eignen. Viel Vergnügen bei der Erörterung!
Und NoSQL?
SQL wurde schon öfter totgesagt – aber aller Konkurrenz zum Trotz ist ein Ende noch nicht abzusehen. Für jeden Einsatzzweck gibt es gute Tools, und in vielen Fällen ist das eben ein sauber designtes, relationales Datenmodell in Verbindung mit SQL und PL/SQL. Wenn diese Basis steht, kann man auch munter die Frameworks auf der Ebene darüber wechseln, je nachdem, was gerade im Trend liegt.
Redaktioneller Hinweis: Sabine Heimsath ist DOAG Themenverantwortliche PL/SQL und Mitglied der Delegiertenversammlung. Darüber hinaus ist sie ein unersetzlicher Faktor in der Mitwirkung der jährlich stattfindenden Low-Code-Konferenz der DOAG namens APEX connect. Auch für die APEX connect 2025 trägt Sabine wieder die Verantwortung für die Ausgestaltung des Streams SQL & PL/SQL. Die Konferenz findet vom 13. bis 15. Mai 2025 im Europa-Park in Rust (Baden-Württemberg) statt. Alle Informationen zur Konferenz, die rund siebzigteilige Agenda sowie Tickets finden sich auf der Website apex.doag.org.
