Kapitel 1. Geschichte und Implementierungen von SQL

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

In den frühen 1970er Jahren führte die bahnbrechende Arbeit des IBM-Forschungsmitarbeiters Dr. E. F. Codd zur Entwicklung eines relationalen Datenmodells namens SEQUEL ( Structured English Query Language). Aus SEQUEL wurde schließlich SQL, die Structured Query Language. Ironischerweise behandelt der SQL-Standard "SQL" als den Namen dieser Sprache und nicht als Akronym. Jim Melton, langjähriger Redakteur des SQL-Standards, behauptet, dass SQL ein Akronym ist und für "SQL Query Language" steht.

IBM wollte zusammen mit anderen Anbietern relationaler Datenbanken eine standardisierte Methode für den Zugriff auf und die Bearbeitung von Daten in einer relationalen Datenbank. Obwohl IBM als erstes Unternehmen die Theorie der relationalen Datenbanken entwickelte, war Oracle das erste Unternehmen, das diese Technologie auf den Markt brachte. Im Laufe der Zeit erwies sich SQL auf dem Markt als so populär, dass das American National Standards Institute (ANSI) in Zusammenarbeit mit der International Standards Organization (ISO) darauf aufmerksam wurde und in den Jahren 1986, 1989, 1992, 1999, 2003, 2008, 2011, 2016 und 2019 Standards für SQL veröffentlichte.

Seit 1986 haben verschiedene konkurrierende Sprachen es Entwicklern ermöglicht, auf relationale Daten zuzugreifen und diese zu bearbeiten. Doch nur wenige waren so leicht zu erlernen oder so allgemein akzeptiert wie SQL. Entwickler und Administratoren haben jetzt den Vorteil, dass sie eine einzige Sprache erlernen können, die mit geringen Anpassungen auf eine Vielzahl von Datenbankplattformen, Anwendungen und Produkten anwendbar ist.

SQL in a Nutshell, 4. Auflage, enthält die Syntax für fünf gängige Implementierungen von SQL:

Der ANSI/ISO SQL-Standard (SQL:2016)
MySQL 8 und MariaDB 10.5
Oracle Datenbank 19c

PostgreSQL 14
Microsoft SQL Server 2019

Das relationale Modell und ANSI SQL

Relationale Datenbankmanagementsysteme (RDBMS), wie sie in diesem Buch behandelt werden, sind die wichtigsten Motoren von Informationssystemen weltweit und insbesondere von Webanwendungen und verteilten Client/Server-Computersystemen. Sie ermöglichen es einer Vielzahl von Benutzern, schnell und gleichzeitig auf Daten zuzugreifen, sie zu erstellen, zu bearbeiten und zu manipulieren, ohne andere Benutzer zu beeinträchtigen. Sie ermöglichen es Entwicklern, nützliche Anwendungen zu schreiben, um auf ihre Ressourcen zuzugreifen, und bieten Administratoren die Möglichkeiten, die sie brauchen, um die Datenressourcen einer Organisation zu pflegen, zu sichern und zu optimieren.

Ein RDBMS ist definiert als ein System, dessen Benutzer die Daten als eine Sammlung von Tabellen betrachten, die durch gemeinsame Datenwerte miteinander verbunden sind. Die Daten werden in Tabellen gespeichert, die aus Zeilen und Spalten bestehen. Tabellen mit unabhängigen Daten können miteinander verknüpft (oder in Beziehung gesetzt) werden, wenn sie jeweils eindeutige, identifizierende Datenspalten (sogenannte Schlüssel) haben, die gemeinsame Datenwerte darstellen. E. F. Codd beschrieb die relationale Datenbanktheorie erstmals in seinem bahnbrechenden Artikel "A Relational Model of Data for Large Shared Data Banks", der im Juni 1970 in den Communications of the ACM (Association for Computing Machinery) veröffentlicht wurde. Nach Codds neuem relationalen Datenmodell waren die Daten strukturiert (in Tabellen mit Zeilen und Spalten), durch Operationen wie Selektionen, Projektionen und Joins verwaltbar und aufgrund von Integritätsregeln wie Schlüsseln und referentieller Integrität konsistent. Diese Begriffe und ihre Definitionen basierten auf früheren mathematischen Konzepten - insbesondere der relationalen Algebra - und sind als solche vollständig beweisbare Theoreme. Codd formulierte auch Regeln, nach denen eine relationale Datenbank aufgebaut werden sollte. Der Prozess der Anwendung dieser Regeln ist heute als Normalisierung bekannt.

Codd's Regeln für relationale Datenbanksysteme

Codd wandte strenge mathematische Theorien (vor allem die relationale Algebra und die Mengenlehre) auf die Verwaltung von Daten an, aus denen er eine Liste von Kriterien zusammenstellte, die eine Datenbank erfüllen muss, um als relational zu gelten. Cobb stellte seine 12 Prinzipien zumindest teilweise auf, um die überschwänglichen Marketingaussagen der vielen Anbieter von DBMS-ähnlichen Produkten einzudämmen, die behaupten wollten, "relational" zu sein. Cobb war sogar so sehr von diesen Prinzipien relationaler Datenbanken als Anti-Hype-Mechanismus überzeugt, dass er ein weiteres wichtiges Grundprinzip aufstellte, das er Regel 0 nannte:

Regel 0: Jedes System, das als relationales Datenbankmanagementsystem beworben wird, muss in der Lage sein, Datenbanken ausschließlich über seine relationalen Fähigkeiten zu verwalten.

Im Kern geht es beim Konzept der relationalen Datenbank darum, Daten in Tabellen zu speichern. Dieses Konzept ist heute so alltäglich, dass es trivial erscheint. Aber erst seit den 1980er Jahren gilt die Idee, ein System zu entwickeln, das das relationale Modell unterstützt, nicht mehr als weit hergeholt und wenig nützlich.

Es folgen Codds zwölf Prinzipien für relationale Datenbanken:

Informationen werden logisch in Tabellen dargestellt.
Die Daten müssen logisch nach Tabelle, Primärschlüssel und Spalte zugänglich sein.
Nullwerte müssen einheitlich als "fehlende Informationen" behandelt werden, nicht als leere Zeichenfolgen, Leerzeichen oder Nullen.
Metadaten (Daten über die Datenbank) müssen genauso in der Datenbank gespeichert werden wie die normalen Daten.
Eine einzige Sprache muss in der Lage sein, Daten, Ansichten, Integritätseinschränkungen, Autorisierung, Transaktionen und Datenmanipulation zu definieren.
Views müssen die Aktualisierungen ihrer Basistabellen anzeigen und umgekehrt.
Für jeden der folgenden Vorgänge muss eine einzige Operation verfügbar sein: Daten abrufen, Daten einfügen, Daten aktualisieren oder Daten löschen.
Batch- und Endbenutzeroperationen sind logisch von der physischen Speicherung und den Zugriffsmethoden getrennt.
Batch- und Endbenutzer-Operationen können das Datenbankschema ändern, ohne dass es oder die darauf aufbauenden Anwendungen neu erstellt werden müssen.
Integritätsbeschränkungen müssen in den Metadaten verfügbar und gespeichert sein, nicht in einem Anwendungsprogramm.
Der Datenmanipulationssprache des relationalen Systems sollte es egal sein, wo oder wie die physischen Daten verteilt sind, und sie sollte nicht geändert werden müssen, wenn die physischen Daten zentralisiert oder verteilt sind.
Alle Zeilenverarbeitungen im System müssen denselben Integritätsregeln und -beschränkungen gehorchen wie die Mengenverarbeitungsvorgänge.

Diese Regeln gelten zwar nicht für die Anwendungsentwicklung, aber sie sind nach wie vor der Lackmustest für die "relationalen" Eigenschaften einer Datenbankplattform; eine Datenbank, die nicht alle diese Regeln erfüllt, ist nicht vollständig relational. Derzeit bestehen die meisten kommerziellen RDBMS-Produkte den Codd-Test, und alle Plattformen, die im Referenzmaterial von SQL in a Nutshell, 4. Der Standard unterstützt auch nicht-relationale Formate wie JSON und XML; wir werden das in Kapitel 10 besprechen.

Das Verständnis der Codd'schen Prinzipien hilft Entwicklern bei der richtigen Entwicklung und Gestaltung von relationalen Datenbanken (RDBs). In den folgenden Abschnitten wird erläutert, wie einige dieser Anforderungen in SQL mit RDBs erfüllt werden.

Datenstrukturen (Regeln 1, 2, 8 und 9)

Die Codd-Regeln 1 und 2 besagen, dass "Informationen logisch in Tabellen dargestellt werden" und dass "Daten logisch nach Tabelle, Primärschlüssel und Spalte zugänglich sein müssen". Bei der Definition einer Tabelle für eine relationale Datenbank ist es also nicht erforderlich, dass die Programme der Datenbank mitteilen, wie sie mit den zugrunde liegenden physischen Datenstrukturen umgehen soll. Außerdem trennt SQL die Prozesse des Datenzugriffs und der physischen Datenpflege logisch voneinander, wie es die Regeln 8 und 9 vorsehen, die besagen, dass Batch- und Endbenutzer-Operationen "logisch von physischen Speicherungs- und Zugriffsmethoden getrennt sind" und "das Datenbankschema ändern können, ohne es oder die darauf aufbauenden Anwendungen neu erstellen zu müssen."

Im relationalen Modell werden die Daten logisch als zweidimensionale Tabelle dargestellt, die eine einzelne Entität beschreibt (z.B. Geschäftsausgaben). Akademiker bezeichnen Tabellen als Entitäten und Spalten als Attribute. Tabellen bestehen aus Zeilen oder Datensätzen (Akademiker nennen sie Tupel) und Spalten ( Attribute genannt, da jede Spalte einer Tabelle ein bestimmtes Attribut der Entität beschreibt). Die Schnittmenge aus einem Datensatz und einer Spalte liefert einen einzigen Wert. Im Sprachgebrauch der Tabellenkalkulation wird dies jedoch häufig als Feld bezeichnet. Die Spalte oder Spalten, deren Werte jeden Datensatz eindeutig identifizieren, können als Primärschlüssel fungieren. Heutzutage scheint diese Darstellung elementar zu sein, aber als sie zum ersten Mal vorgeschlagen wurde, war sie tatsächlich ziemlich innovativ.

Der SQL-Standard definiert eine ganze Hierarchie von Datenstrukturen, die über einfache Tabellen hinausgeht, auch wenn Tabellen die zentrale Datenstruktur sind. Beim relationalen Design werden die Daten Tabelle für Tabelle und nicht Datensatz für Datensatz verarbeitet. Diese tabellenzentrierte Ausrichtung ist das Herzstück der Mengenprogrammierung. Folglich arbeiten fast alle SQL-Befehle viel effizienter mit Datenmengen in oder zwischen Tabellen als mit einzelnen Datensätzen. Anders ausgedrückt: Effektive SQL-Programmierung erfordert, dass du in Datenmengen und nicht in einzelnen Zeilen denkst.

Abbildung 1-1 zeigt die SQL-Terminologie, die zur Beschreibung der hierarchischen Datenstrukturen einer relationalen Datenbank verwendet wird: Kataloge enthalten Gruppen von Schemas; Schemas enthalten Gruppen von Objekten, wie z. B. Tabellen und Ansichten; und Tabellen bestehen aus Gruppen von Spalten und Datensätzen.

In einer Business_Expense-Tabelle könnte zum Beispiel eine Spalte mit dem Namen Expense_Date anzeigen, wann eine Ausgabe entstanden ist. Jeder Datensatz in der Tabelle beschreibt eine bestimmte Einheit, in diesem Fall alles, was eine Geschäftsausgabe ausmacht (wann sie entstanden ist, wie viel sie gekostet hat, wer die Ausgabe getätigt hat, wofür sie verwendet wurde usw.).

Jedes Attribut einer Ausgabe - mit anderen Worten: jede Spalte - soll atomar sein, d.h. jede Spalte soll nur einen und nur einen Wert enthalten. Wenn eine Tabelle erstellt wird, in der der Schnittpunkt einer Zeile und einer Spalte mehr als einen unterschiedlichen Wert enthalten kann, wurde eine der wichtigsten Entwurfsrichtlinien von SQL verletzt. (Einige der in diesem Buch besprochenen Datenbankplattformen erlauben es jedoch, mehr als einen Wert in einer Spalte zu speichern, und zwar über die Datentypen VARRAY oder TABLE oder, in den letzten Jahren häufiger, XML oder JSON ).

Für Spaltenwerte gibt es bestimmte Verhaltensregeln. An erster Stelle steht, dass die Spaltenwerte einen gemeinsamen Bereich haben müssen, besser bekannt als Datentyp. Wenn z. B. für das Feld Aufwand_Datum der Datentyp DATE definiert ist, kann der Wert ELMER nicht in dieses Feld eingegeben werden, da es sich um eine Zeichenkette und nicht um ein Datum handelt und das Feld Aufwand_Datum nur Datumsangaben enthalten kann. Darüber hinaus ermöglicht der SQL-Standard eine weitere Kontrolle der Spaltenwerte durch die Anwendung von Einschränkungen (die in Kapitel 2 ausführlich behandelt werden) und Behauptungen. Eine SQL-Beschränkung könnte zum Beispiel beim Einfügen eines neuen Spesendatensatzes sicherstellen, dass der Wert des Spesendatums nicht älter als 90 Tage ist, was den Unternehmensrichtlinien für die Spesenabrechnung entspricht.

Außerdem wird der Datenzugriff für alle Personen und Computerprozesse auf Schemaebene durch eine AuthorizationID oder einen Benutzer kontrolliert. Die Erlaubnis, auf bestimmte Daten zuzugreifen oder sie zu ändern, kann für jeden Benutzer einzeln erteilt oder eingeschränkt werden.

SQL-Datenbanken verwenden auch Zeichensätze und Sortierungen. Zeichensätze sind die "Symbole" oder "Alphabete", die von der "Sprache" der Daten verwendet werden. Der Zeichensatz für amerikanisches Englisch enthält zum Beispiel nicht das Sonderzeichen für ñ im spanischen Zeichensatz. Kollationen sind Sortierregeln, die auf einen Zeichensatz angewendet werden. Eine Sortierung legt fest, wie eine bestimmte Datenverarbeitungsoperation die Daten sortiert. Ein amerikanisch-englischer Zeichensatz kann zum Beispiel entweder nach der Reihenfolge der Zeichen ohne Berücksichtigung der Groß- und Kleinschreibung oder nach der Reihenfolge der Zeichen mit Berücksichtigung der Groß- und Kleinschreibung sortiert werden.

Der SQL-Standard schreibt nicht vor, wie die Daten sortiert werden sollen, sondern nur, dass die Plattformen die in einer bestimmten Sprache üblichen Sortierungen bereitstellen müssen.

Es ist wichtig zu wissen, welche Sortierreihenfolge du verwendest, wenn du SQL-Code für eine Datenbankplattform schreibst, denn sie kann sich direkt auf das Verhalten von Abfragen auswirken, insbesondere auf das Verhalten der Klauseln einer SELECT -Anweisung, wie WHERE, ORDER BY, GROUP BY und PARTITION BY. Eine Abfrage, die Daten mit einer binären Sortierung sortiert, wird beispielsweise Daten in einer ganz anderen Reihenfolge zurückliefern als eine Abfrage, die Daten z. B. mit einer schwedischen Sortierung sortiert. Dies ist auch sehr wichtig, wenn du SQL-Code zwischen verschiedenen Datenbankplattformen migrierst, da das Standard-Sortierverhalten sehr unterschiedlich sein kann. So wird bei Oracle normalerweise die Groß- und Kleinschreibung beachtet, während dies bei Microsoft SQL Server nicht der Fall ist. Wenn du eine unveränderte Abfrage von Oracle auf SQL Server überträgst, kann das zu einer völlig anderen Ergebnismenge führen, weil Oracle Werte wie "Halloween" und "HALLOWEEN" als ungleich bewertet, während SQL Server sie standardmäßig als gleich ansieht.

NULLen (Regel 3)

Die meisten Datenbanken erlauben es, in jedem ihrer unterstützten Datentypen NULL-Werte zu speichern. Unerfahrene SQL-Entwickler neigen dazu, NULL-Werte als Zeichenketten mit der Länge Null zu betrachten, aber in SQL bedeutet NULL wörtlich, dass der Wert unbekannt oder unbestimmt ist. (Allein diese Frage - ob NULL als unbekannt oder unbestimmt angesehen werden sollte - ist Gegenstand vieler akademischer Debatten.) Diese Unterscheidung ermöglicht es einem Datenbankdesigner, zwischen Einträgen zu unterscheiden, die z. B. eine absichtlich gesetzte Null darstellen, und solchen, bei denen entweder die Daten nicht im System erfasst sind oder explizit eine NULL eingegeben wurde. Um diesen semantischen Unterschied zu verdeutlichen, nimm ein System, das Zahlungen erfasst. Wenn ein Produkt einen NULL-Preis hat, bedeutet das nicht, dass das Produkt kostenlos ist; stattdessen zeigt ein NULL-Preis an, dass der Betrag nicht bekannt ist oder vielleicht noch nicht festgelegt wurde.

Die Datenbankplattformen unterscheiden sich stark darin, wie sie mit NULL-Werten umgehen. Das führt zu einigen großen Problemen bei der Portierung dieser Werte. Zum Beispiel wird ein leerer String (d.h. ein NULL-String) bei Oracle als NULL-Wert eingefügt. Alle anderen Datenbanken, die in diesem Buch behandelt werden, erlauben das Einfügen eines leeren Strings in die Spalten VARCHAR und CHAR.

Ein Nebeneffekt der unbestimmten Natur eines NULL-Wertes ist, dass er nicht in einer Berechnung oder einem Vergleich verwendet werden kann. Hier sind ein paar kurze, aber sehr wichtige Regeln aus dem ANSI/ISO-Standard, an die du dich beim Umgang mit NULL-Werten in SQL-Anweisungen erinnern solltest:

Ein NULL-Wert kann nicht in eine Spalte eingefügt werden, die mit der Einschränkung NOT NULL definiert ist.
NULL-Werte sind nicht gleichwertig. Es ist ein häufiger Fehler, zwei Spalten zu vergleichen, die NULL enthalten, und zu erwarten, dass die NULL-Werte übereinstimmen. (Die richtige Art, einen NULL-Wert in einer WHERE Klausel oder in einem booleschen Ausdruck zu identifizieren, ist die Verwendung von Ausdrücken wie "Wert IST NULL" und "Wert IST NICHT NULL").
Eine Spalte, die einen NULL-Wert enthält, wird bei der Berechnung von Aggregatwerten wie AVG, SUM oder MAX COUNT ignoriert.
Wenn Spalten, die NULL-Werte enthalten, in der GROUP BY Klausel einer Abfrage aufgeführt sind, enthält die Abfrageausgabe eine einzige Zeile für NULL-Werte. Im Wesentlichen betrachtet der ANSI/ISO-Standard alle gefundenen NULL-Werte als eine einzige Gruppe.
DISTINCT und ORDER BY Klauseln, wie GROUP BY, sehen auch NULL-Werte als nicht voneinander unterscheidbar an. Mit der ORDER BY Klausel kann der Anbieter frei wählen, ob NULL-Werte standardmäßig hoch (zuerst in der Ergebnismenge) oder niedrig (zuletzt in der Ergebnismenge) sortiert werden. Bei einigen Datenbankanbietern kannst du mit den Schlüsselwörtern NULL FIRST oder NULL LAST festlegen, wie NULL-Werte pro Abfrage sortiert werden sollen.

Metadaten (Regeln 4 und 10)

Codds vierte Regel für relationale Datenbanken besagt, dass Daten über die Datenbank in Standardtabellen gespeichert werden müssen, so wie alle anderen Daten auch. Daten, die die Datenbank selbst beschreiben, werden Metadaten genannt. Jedes Mal, wenn du zum Beispiel eine neue Tabelle oder Ansicht in einer Datenbank erstellst, werden Datensätze erstellt und gespeichert, die die neue Tabelle beschreiben. Zusätzliche Datensätze werden benötigt, um alle Spalten, Schlüssel oder Einschränkungen der Tabelle zu speichern. Diese Technik ist in den meisten kommerziellen und Open-Source-SQL-Datenbankprodukten implementiert. SQL Server zum Beispiel verwendet so genannte "Systemtabellen", um alle Informationen über die Datenbanken, Tabellen und Datenbankobjekte in einer bestimmten Datenbank zu erfassen. Außerdem gibt es "Systemdatenbanken", in denen Informationen über den Server gespeichert werden, auf dem die Datenbank installiert und konfiguriert ist.

Zusätzlich zu den Systemtabellen definiert der SQL-Standard eine Reihe grundlegender Metadaten, die über eine weit verbreitete Reihe von Ansichten verfügbar sind, die in einem speziellen Schema namens INFORMATION_SCHEMA gespeichert werden. Insbesondere Oracle (seit 2015) und IBM DB2 unterstützen dieses Schema nicht. In der Praxis sollte dies kein Problem darstellen, da es Open-Source-Skripte gibt, die die Katalogansichten der Oracle-Datenbank auf das Format des SQL-Standards INFORMATION_SCHEMA abbilden.

Die Sprache (Regeln 5 und 11)

Die Regeln von Codd verlangen nicht, dass SQL mit einer relationalen Datenbank verwendet wird. Seine Regeln, insbesondere die Regeln 5 und 11, legen nur fest, wie sich die Sprache in Verbindung mit einer relationalen Datenbank verhalten soll. Früher konkurrierte SQL mit anderen Sprachen (z. B. RDO und Fox/PRO von Digital), die ebenfalls für relationale Datenbanken geeignet waren, aber SQL setzte sich aus drei Gründen durch. Erstens ist SQL eine relativ einfache, intuitive, englischsprachige Sprache, die die meisten Aspekte der Datenverarbeitung beherrscht. Wenn du Englisch lesen und sprechen kannst, macht SQL einfach Sinn. Zweitens ist SQL eine zufriedenstellende Hochsprache. Ein Entwickler oder Datenbankadministrator (DBA) muss keine Zeit darauf verwenden, sicherzustellen, dass die Daten in den richtigen Speicherregistern gespeichert werden oder dass die Daten von der Festplatte in den Speicher übertragen werden; das Datenbankmanagementsystem (DBMS) erledigt diese Aufgabe automatisch. Da SQL nicht von einem einzigen Anbieter stammt, wurde es von einer Reihe von Plattformen übernommen, was eine breite Unterstützung und große Popularität gewährleistet.

Ansichten (Regel 6)

Eine Ansicht ist eine virtuelle Tabelle, die nicht als physischer Datenspeicher existiert, sondern bei jeder Abfrage dieser Ansicht aus einer SELECT -Anweisung erstellt wird. Mit Views kannst du unterschiedliche Darstellungen derselben Quelldaten für verschiedene Zielgruppen erstellen, ohne die Art und Weise, wie die Daten gespeichert werden, ändern zu müssen.

Einige Anbieter unterstützen Datenbankobjekte, die materialisierte Ansichten genannt werden, auch bekannt als indizierte Ansichten. Lass dich von der Ähnlichkeit dieser Begriffe nicht verwirren; materialisierte Ansichten unterliegen nicht denselben Regeln wie SQL-Standardansichten.

Mengenoperationen (Regeln 7 und 12)

Andere Datenbankmanipulationssprachen wie Ruby on Rails, Django und LINQ für .NET führen ihre Datenoperationen ganz anders aus als SQL. Bei diesen Sprachen musst du dem Programm genau sagen, wie es die Daten behandeln soll, und zwar einen Datensatz nach dem anderen. Da das Programm eine Liste von Datensätzen iterativ durchläuft und seine Logik für einen Datensatz nach dem anderen ausführt, wird diese Art der Programmierung häufig als Zeilenverarbeitung oder prozedurale Programmierung bezeichnet.

Im Gegensatz dazu arbeiten SQL-Programme mit logischen Datenmengen. Die Mengenlehre wird in fast allen SQL-Anweisungen angewandt, so auch in den Anweisungen SELECT, INSERT, UPDATE und DELETE. Die Daten werden aus einer Menge, der "Tabelle", ausgewählt. Anders als bei der Zeilenverarbeitung kann der Programmierer bei der Mengenverarbeitung der Datenbank lediglich mitteilen , was benötigt wird, und nicht , wie die einzelnen Daten verarbeitet werden sollen. Manchmal wird die Mengenverarbeitung auch als deklarative Verarbeitung bezeichnet, da der Entwickler nur angibt, welche Daten er benötigt (z. B. "Gib alle Arbeitnehmer in der Region Süd zurück, die mehr als 70.000 US-Dollar pro Jahr verdienen"), anstatt die genauen Schritte zum Abrufen oder Verarbeiten der Daten zu beschreiben.

Die Mengenlehre geht auf den Mathematiker Georg Cantor zurück, der sie Ende des 19. Jahrhunderts entwickelte. Damals war die Mengenlehre (und Cantors Theorie des Unendlichen) ziemlich umstritten. Heute ist die Mengenlehre ein so alltäglicher Bestandteil des Lebens, dass sie bereits in der Grundschule gelernt wird. Dinge wie die Auswahlkataloge deines Lieblingsfilmstreamingdienstes, Online-Konsolenspiele und beliebte Musikanwendungen sind alles einfache und alltägliche Beispiele für angewandte Mengenlehre.

Relationale Datenbanken verwenden die relationale Algebra und die Tupel-Relationsrechnung, um die Daten in einer bestimmten Datenbank und die Abfragen, die auf diese Daten wirken, mathematisch zu modellieren. Diese Theorien wurden ebenfalls von E. F. Codd eingeführt, zusammen mit seinen 12 Regeln für relationale Datenbanken.

Beispiele für die Mengenlehre in Verbindung mit relationalen Datenbanken werden im folgenden Abschnitt erläutert.

Codd's Regeln in Aktion: Einfache SELECT-Beispiele

Bis zu diesem Punkt hat sich dieses Kapitel auf die einzelnen Aspekte einer relationalen Datenbankplattform konzentriert, wie sie von Codd definiert und durch den SQL-Standard implementiert wurde. Dieser Abschnitt gibt einen Überblick über die wichtigste SQL-Anweisung SELECT und einige ihrer wichtigsten Punkte, nämlich die folgenden drei relationalen Operationen:

Projektionen: Rufe bestimmte Spalten von Daten ab.
Auswahlen: Rufe bestimmte Datenzeilen ab.
Tritt bei: Gib Spalten und Zeilen aus zwei oder mehr Tabellen in einer einzigen Ergebnismenge zurück.

Auch wenn es auf den ersten Blick so aussehen mag, als ob die Anweisung SELECT nur die relationale Auswahloperation betrifft, so betrifft SELECT in Wirklichkeit alle drei Operationen.

Die folgende Anweisung verkörpert die Projektionsoperation, indem sie den Vor- und Nachnamen eines Autors sowie seinen Heimatstaat aus der Autorentabelle auswählt:

SELECT au_fname, au_lname, state
FROM   authors;

Die Ergebnisse einer solchen SELECT Aussage werden als weitere Datentabelle dargestellt:

au_fname             au_lname                           state
----------------  ---------------------------- ----------------
Johnson              White                              CA
Marjorie             Green                              CA
Cheryl               Carson                             CA
Michael              O’Leary                            CA
Meander              Smith                              KS
Morningstar          Greene                             TN
Reginald             Blotchet-Halls                     OR
Innes                del Castillo                       MI

Die resultierenden Daten werden manchmal als Ergebnismenge, Arbeitstabelle oder abgeleitete Tabelle bezeichnet, um sie von der Basistabelle in der Datenbank zu unterscheiden, die das Ziel der SELECT Anweisung ist.

Es ist wichtig zu beachten, dass die relationale Operation der Projektion, nicht die Selektion, mit der SELECT Klausel (d.h. dem Schlüsselwort SELECT gefolgt von einer Liste von Ausdrücken, die abgerufen werden sollen) einer SELECT Anweisung angegeben wird. Die Auswahl, d. h. der Abruf bestimmter Datenzeilen, wird mit der Klausel WHERE in einer SELECT Anweisung angegeben. WHERE filtert unerwünschte Datenzeilen heraus und ruft nur die gewünschten Zeilen ab. Um das vorherige Beispiel fortzusetzen, wählt die folgende Anweisung Autoren aus anderen Staaten als Kalifornien aus:

SELECT au_fname, au_lname, state
FROM   authors
WHERE  state <> 'CA';

Während bei der ersten Abfrage alle Autoren gefunden wurden, ist das Ergebnis dieser zweiten Abfrage eine viel kleinere Gruppe von Datensätzen:

au_fname            au_lname                           state
---------------- ----------------------------------- -------------
Meander             Smith                              KS
Morningstar         Greene                             TN
Reginald            Blotchet-Halls                     OR
Innes               del Castillo                       MI

Verschiedene Anbieter erlauben es dir, eine unterschiedliche Anzahl von Tabellen in einer einzigen Abfrage zu verbinden. Während ältere Datenbankplattformen nicht mehr als 256 Joins innerhalb einer Abfrage zuließen, sind die meisten Datenbankplattformen heute nur noch durch die verfügbaren Systemressourcen begrenzt.

Bedenke jedoch, dass deine Datenbank-Engine mehr Systemressourcen verbraucht und eine höhere Latenzzeit aufweist, je mehr Tabellen du in einer einzigen Abfrage verbindest. Eine einzige SELECT -Anweisung, die 12 Tabellen verknüpft, muss zum Beispiel bis zu 28.158.588.057.600 mögliche Join-Orders berücksichtigen.

Die heutigen Optimierer für Datenbankabfragen sind sehr ausgeklügelt und nutzen kostenbasierte Optimierungen und Heuristiken, um Abfragen mit einem Dutzend oder mehr Joins zu einer überschaubaren Aufgabe zu machen. Viele erfahrene SQL-Entwickler versuchen jedoch, ihre SELECT Anweisungen auf 16 oder weniger Joins zu beschränken, um die Abfragelogik leicht verständlich zu halten. In anderen Situationen können erfahrene SQL-Entwickler alternative Programmierpraktiken wie Common Table Expressions (CTEs), temporäre Tabellen oder Unterabfragen verwenden, um eine gute Leistung zu erzielen.

Durch die Kombination der Funktionen von Projektion und Auswahl in einer einzigen Abfrage kannst du mit SQL nur die Spalten und Datensätze abrufen, die du zu einem bestimmten Zeitpunkt benötigst.

Joins sind die nächste und letzte relationale Operation, die in diesem Abschnitt behandelt wird. Eine Verknüpfung verknüpft eine Tabelle mit einer anderen, um eine Ergebnismenge zu erhalten, die aus zusammengehörigen Daten aus beiden Tabellen besteht.

Die ANSI/ISO-Standardmethode zur Durchführung von Joins ist die Verwendung der JOIN -Klausel in einer SELECT -Anweisung. Eine ältere Methode, manchmal auch Theta-Join genannt, analysiert das Join-Suchargument in der WHERE Klausel. Das folgende Beispiel zeigt beide Ansätze. Jede Anweisung ruft Mitarbeiterinformationen aus der Basistabelle " Mitarbeiter" sowie Stellenbeschreibungen aus der Basistabelle " Aufträge" ab. Die erste SELECT verwendet die neuere ANSI/ISO SQL JOIN Klausel, während die zweite SELECT einen Theta-Join verwendet:

-- ANSI/ISO style
SELECT a.au_fname, a.au_lname, t.title_id
FROM   authors AS a
JOIN   titleauthor AS t ON a.au_id = t.au_id
WHERE  a.state <> 'CA';

-- Theta style
SELECT a.au_fname, a.au_lname, t.title_id
FROM   authors AS a,
       titleauthor AS t
WHERE  a.au_id = t.au_id
   AND a.state <> 'CA';

Obwohl Theta-Joins von allen Plattformen unterstützt werden und keine Leistungseinbußen mit sich bringen, gilt dies als minderwertiges Codierungsmuster, da jeder, der die Abfrage liest oder pflegt, die Argumente, die zur Definition der Join-Bedingung verwendet werden, nicht sofort von denen unterscheiden kann, die als Filterbedingungen dienen.

Es gibt noch mehr Probleme mit Theta-Joins als die einfache Lesbarkeit. Oracle erlaubt zum Beispiel nur einen Outer-Join-Vergleich mit(+), was beim logischen Aufbau eines Outer-Joins mit einem mehrspaltigen Schlüssel ein ziemliches Problem darstellen kann. In einer solchen Situation kann es schwierig sein, Syntaxfehler zu vermeiden oder sogar die falsche Ergebnismenge zu erhalten.

Weitere Informationen über Joins findest du in der "JOIN Subclause".

Geschichte des SQL-Standards

Als Reaktion auf die Verbreitung von SQL-Dialekten veröffentlichte die ANSI 1986 ihren ersten SQL-Standard, um eine größere Konformität zwischen den Anbietern zu erreichen. Dieser wurde 1987 von der ISO anerkannt und 1989 folgte ein zweiter, weit verbreiteter Standard (ebenfalls von der ISO anerkannt). ANSI/ISO veröffentlichten 1992 ihre erste gemeinsame Aktualisierung, bekannt als SQL2, SQL-92 oder SQL:1992, und 1999 eine zweite, die als SQL3, SQL-99 oder SQL:1999 bezeichnet wurde. Die nächste Aktualisierung aus dem Jahr 2003 wird als SQL:2003 bezeichnet und so weiter.

Zwischen der Veröffentlichung von SQL:1992 und der Entwicklung von SQL:1999 wurden die SQL-Spezifikationsentwürfe in SQL3 und SQL4 aufgeteilt. Der SQL4-Entwurf wurde jedoch gekürzt, und der SQL3-Entwurf wurde als SQL:1999 angenommen. Ab diesem Zeitpunkt wurden die Namen der SQL-Standards dauerhaft in SQL:yyyy umbenannt.

Mit jeder Überarbeitung des SQL-Standards, der offiziell als ISO/IEC 9075 Database Language SQL bekannt ist, werden neue Funktionen hinzugefügt und neue Befehle und Möglichkeiten in die Sprache integriert. Hier ist eine kurze Liste der Versionen und einiger ihrer wichtigsten Beiträge (Funktionen oder Spezifikationen):

SQL-87: Standard, der erstmals von ANSI formalisiert wurde; Unterstützung für Transaktionen und die Operationen CREATE, READ, UPDATE und DELETE
SQL-89: Geringfügige Überarbeitung, Hinzufügen von referenziellen Integritätsbeschränkungen
SQL-92: Große Überarbeitung (ISO 9075), zusätzliche Unterstützung für Internationalisierung usw.
SQL:1999: Unterstützung für benutzerdefinierte Typen, die Zuordnung regulärer Ausdrücke, Trigger, prozedurale und Kontrollflussanweisungen und mehr
SQL:2003: Unterstützung für XML und OLAP (Fensterfunktionen), Sampling und erweiterte numerische Funktionen hinzugefügt
SQL:2006: Klärung des Zusammenspiels von SQL und SML und Unterstützung für XQuery
SQL:2008: Übernahme verschiedener Verbesserungen und Erweiterungen, die in mehreren der bekanntesten RDBMS-Plattformen vorgenommen wurden (INSTEAD OF triggers, TRUNCATE statement, FETCH clause, etc.) und Erweiterung der XML-Spezifikation
SQL:2011: Einführung neuer Funktionen für die Verwaltung zeitlicher Daten
SQL:2016: Beschrieben, wie SQL mit der JavaScript Object Notation (JSON) interagiert und Unterstützung für polymorphe Tabellenfunktionen und Zeilenmustervergleiche hinzugefügt
SQL:2019: Beschrieben, wie SQL mit multidimensionalen Arrays (MDAs) interagiert

Die in SQL:2019 hinzugefügten Funktionen und die geplante SQL/PGQ (Graph Query Language)-Erweiterung werden von den in dieser Ausgabe von SQL in a Nutshell betrachteten Produkten noch nicht unterstützt, daher erstreckt sich unsere Berichterstattung in diesem Buch nur auf SQL:2016. SQL:2019 wird in zukünftigen Ausgaben behandelt.

Stufen der Konformität

Mit SQL-92 wurden drei Konformitätsstufen eingeführt, die den Grad der Übereinstimmung mit dem Standard angeben: Entry, Intermediate und Full (das U.S. National Institute of Standards and Technology fügte später eine Transitional-Stufe zwischen den ersten beiden hinzu). Die Anbieter mussten mindestens die Einstiegsstufe erreichen, um die ANSI/ISO SQL-Konformität zu erreichen. Jede höhere Stufe des Standards war eine Obermenge der untergeordneten Stufe, d.h. jede höhere Stufe umfasste alle Funktionen der niedrigeren Konformitätsstufen.

Später änderte SQL:1999 die Basisstufen der Konformität und schaffte die ursprünglichen drei Kategorien ab. Stattdessen wurde von den Anbietern verlangt, ein Minimum an obligatorischen Funktionen zu implementieren, die als "Core SQL" bezeichnet werden, damit sie behaupten (und damit werben) können, dass sie SQL:1999-konform sind. Dazu gehörten das alte Entry Level SQL-92 Feature Set, Features aus anderen SQL-92 Levels und einige neue Features. Die Anbieter konnten sich auch dafür entscheiden, zusätzliche Teile des Standards zu implementieren, die im nächsten Abschnitt beschrieben werden.

Teile des SQL-Standards

Seit SQL:1999 ist der SQL-Standard in eine Reihe von Teilen unterteilt, die mit 1 bis 14 nummeriert sind (Stand: SQL:2016). Nicht alle dieser Teile wurden veröffentlicht, und nicht alle haben sich durchgesetzt. Die folgende Liste beschreibt die verschiedenen Teile des Standards:

Teil 1, SQL/Rahmenwerk: Enthält gemeinsame Definitionen und Konzepte, die in der gesamten Norm verwendet werden. Legt fest, wie der Standard strukturiert ist und wie die verschiedenen Teile zueinander in Beziehung stehen, und beschreibt die Konformitätsanforderungen, die vom Normenausschuss festgelegt wurden.
Teil 2, SQL/Grundlagen: Enthält den Kern, die zentralen Elemente der Sprache, einschließlich der obligatorischen und optionalen Funktionen. Dies ist der größte und wichtigste Teil des Standards.
Teil 3, SQL/CLI (Call-Level Interface): Definiert die Call-Level-Schnittstelle für den dynamischen Aufruf von SQL-Anweisungen aus externen Anwendungsprogrammen. Enthält außerdem mehr als 60 Routinespezifikationen, die die Entwicklung von wirklich portabler Shrinkwrapped Software erleichtern.
Teil 4, SQL/PSM (Persistent Stored Modules): Standardisiert prozedurale Sprachkonstrukte, die denen in plattformspezifischen SQL-Dialekten wie PL/SQL und Transact-SQL ähnlich sind.
Teil 9, SQL/MED (Verwaltung von externen Daten): Definiert die Verwaltung von Daten, die sich außerhalb der Datenbankplattform befinden, mithilfe von Datenlinks und einer Wrapper-Schnittstelle.
Teil 10, SQL/OLB (Object Language Binding): Beschreibt, wie man SQL-Anweisungen in Java-Programme einbettet. Sie ist eng mit JDBC verwandt, bietet aber einige Vorteile. Außerdem unterscheidet sie sich stark von der traditionellen Host-Sprachbindung, die in frühen Versionen des Standards möglich war.
Teil 11, SQL/Schemata: Definiert über 85 Ansichten, die zur Beschreibung der Metadaten jeder Datenbank dienen und in einem speziellen Schema namens INFORMATION_SCHEMA gespeichert werden.
Teil 13, SQL/JRT (Java-Routinen und -Typen): Definiert eine Reihe von SQL-Routinen und -Typen unter Verwendung der Programmiersprache Java. Mehrere Java-Funktionen, wie statische Java-Methoden und -Klassen, werden unterstützt.
Teil 14, SQL/XML: Fügt einen neuen Typ namens XML, vier neue Operatoren (XMLPARSE, XMLSERIALIZE, XMLROOT und XMLCONCAT), mehrere neue Funktionen (beschrieben in Kapitel 7) und das neue Prädikat IS DOCUMENT hinzu. Enthält außerdem Regeln für die Abbildung von SQL-bezogenen Elementen (wie Bezeichner, Schemata und Objekte) auf XML-bezogene Elemente.

Es gibt auch einen Teil 15, SQL/MDA, der, wie bereits erwähnt, erst 2019 erschien und nicht im SQL:2016 Standard enthalten ist. Beachte, dass die Teile 5-8 und 12 absichtlich nicht für die Öffentlichkeit freigegeben wurden. Die Teile 5 und 8 wurden ursprünglich innerhalb von Teil 2, SQL/Foundation, definiert, dann ausgegliedert, aber später wieder in denselben Teil eingegliedert. Die Teile 7 und 12 wurden aufgrund mangelnder Fortschritte gestrichen, und die Hauptanforderung für Teil 7, die zeitliche Unterstützung, wurde schließlich in SQL:2011 in Teil 2 aufgenommen.

Der SQL-Standard, der die Abfrage, Bearbeitung und Verwaltung von Daten umfasst, formalisiert viele SQL-Verhaltensweisen und Syntaxstrukturen für eine Vielzahl von Plattformen. Dieser Standard ist noch wichtiger geworden, seit Open-Source-Datenbankprodukte wie MySQL und PostgreSQL an Beliebtheit gewonnen haben und von virtuellen Teams statt von großen Unternehmen entwickelt werden.

Beachte, dass eine RDBMS-Plattform die Erfüllung der grundlegenden Core SQL:1999-Standards als SQL-Konformität beanspruchen kann. Daher solltest du das Kleingedruckte des Herstellers lesen, um eine vollständige Beschreibung der ANSI/ISO-Konformität zu erhalten. Wenn du die verschiedenen Teile des Standards verstehst, kannst du dir ein besseres Bild von den Fähigkeiten eines bestimmten RDBMS machen und herausfinden, wie sich verschiedene Funktionen verhalten, wenn SQL-Code zu anderen Datenbankprodukten übertragen wird.

Dieses Buch beschreibt die SQL-Implementierungen von vier gängigen RDBMS. Diese Anbieter unterstützen nicht alles, was im SQL-Standard definiert ist. Alle RDBMS-Plattformen spielen ein ständiges Spiel mit den Standardisierungsgremien, die die Benchmark oft aktualisieren, verfeinern oder anderweitig ändern, sobald die Anbieter beginnen, sich dem Standard anzunähern. Umgekehrt implementieren die Anbieter oft neue Funktionen, die noch nicht Teil des Standards sind, die aber die Effektivität ihrer Nutzer erhöhen.

SQL-Anweisungs-Klassen

In SQL-92 wurden die Anweisungen in drei große Kategorien eingeteilt:

Datenmanipulationssprache (DML): Bietet spezielle Befehle zur Datenmanipulation wie SELECT, INSERT, UPDATE und DELETE
Datendefinitionssprache (DDL): Enthält Befehle, die den Zugriff auf und die Manipulation von Datenbankobjekten regeln, wie CREATE und DROP
Data Control Language (DCL): Enthält erlaubnisbezogene Befehle wie GRANT und REVOKE

Im Gegensatz dazu werden in SQL:1999 und späteren Versionen sieben Kernkategorien oder Klassen definiert, die einen allgemeinen Rahmen für die in SQL verfügbaren Befehlstypen bilden. Dieser neue Rahmen versucht, die Anweisungen innerhalb jeder Klasse genauer und logischer zu identifizieren, und ermöglicht die Entwicklung neuer Funktionen und Anweisungsklassen. Außerdem konnten so einige "verwaiste" Anweisungen, die in keine der alten Kategorien passten, richtig klassifiziert werden.

Tabelle 1-1 zeigt die SQL-Anweisungsklassen und listet einige der Befehle in jeder Klasse auf, die später ausführlich behandelt werden. An dieser Stelle ist es wichtig, sich die Titel der Anweisungsklassen zu merken.

Tabelle 1-1. SQL-Anweisungsklassen
Klasse	Beschreibung	Beispiel-Befehle
Verbindungsanweisungen	Starte und beende eine Client-Verbindung.	`CONNECT`, `DISCONNECT`
Kontrollanweisungen	Steuern Sie die Ausführung einer Reihe von SQL-Anweisungen.	`CALL`, `RETURN`
Datenangaben	Kann eine dauerhafte und anhaltende Wirkung auf Daten haben.	`SELECT`, `INSERT`, `UPDATE`, `DELETE`
Diagnostische Aussagen	Diagnoseinformationen bereitstellen und Ausnahmen und Fehler melden.	`GET DIAGNOSTICS`
Schema-Anweisungen	Kann eine dauerhafte und nachhaltige Wirkung auf ein Datenbankschema und die darin enthaltenen Objekte haben.	`ALTER`, `CREATE`, `DROP`
Session Aussagen	Kontrolliere das Standardverhalten und andere Parameter für eine Sitzung.	`SET` Aussagen wie `SET CONSTRAINT`
Transaktionsaufstellungen	Lege den Start- und Endpunkt einer Transaktion fest.	`COMMIT`, `ROLLBACK`

Diejenigen, die regelmäßig mit SQL arbeiten, sollten sich sowohl mit den alten (SQL-92) als auch mit den neuen (SQL:1999 und später) Anweisungsklassen vertraut machen, da beide Nomenklaturen immer noch verwendet werden, um sich auf SQL-Funktionen und Anweisungen zu beziehen.

SQL-Dialekte

Die ständige Weiterentwicklung des SQL-Standards hat zu einer Reihe von SQL-Dialekten unter den verschiedenen Anbietern und Plattformen geführt. Diese Dialekte entstanden in der Regel, weil die Nutzer eines bestimmten Datenbankanbieters neue Funktionen für die Datenbank forderten, bevor die ANSI/ISO-Ausschüsse die entsprechenden Standards ausarbeiteten (manchmal viele Jahre zuvor). Gelegentlich hat auch die akademische Gemeinschaft oder die Forschung neue Funktionen eingeführt, um auf den Druck der konkurrierenden Technologien zu reagieren. So haben zum Beispiel viele Datenbankanbieter ihr aktuelles Programmangebot um JSON und XML erweitert oder andere Möglichkeiten gefunden, Funktionen anzubieten, die in nicht-relationalen Datenbankplattformen zu finden sind(in Kapitel 10 wird beschrieben, wie XML und JSON zur Speicherung und Abfrage nicht-relationaler Daten in einer relationalen Datenbank verwendet werden können).

Viele dieser Dialekte enthalten Funktionen für die bedingte Verarbeitung (z. B. solche, die die Verarbeitung durch IF ... THEN Anweisungen steuern), Funktionen für die Ablaufsteuerung (z. B. WHILE Schleifen), Variablen und Funktionen für die Fehlerbehandlung. Da die ANSI/ISO-Ausschüsse noch keine Standards für diese wichtigen Funktionen entwickelt hatten, als die Benutzer sie zu fordern begannen, entwickelten die RDBMS-Anbieter ihre eigenen Befehle und ihre eigene Syntax. Bei einigen der ersten Anbieter aus den 1980er Jahren gibt es sogar Abweichungen bei den elementarsten Befehlen, wie z. B. SELECT, weil ihre Implementierungen vor der Einführung der Standards erfolgten. Wenn du versuchst, SQL-Code zu erstellen, der zwischen verschiedenen Datenbankplattformen interoperabel ist, solltest du bedenken, dass deine Erfahrungen unterschiedlich ausfallen können.

Teil 4 des Standards bietet viele Funktionen, die mit der Programmierung von Stored Procedures verbunden sind, und enthält viele der von diesen Dialekten angebotenen Erweiterungen.

Einige beliebte Dialekte von SQL sind:

PL/pgSQL: Der SQL-Dialekt und die Erweiterungen, die in PostgreSQL implementiert sind. Das Akronym steht für Procedural Language/PostgreSQL.
PL/SQL: Oracles prozedurale Erweiterung zu SQL. PL/SQL steht für Procedural Language/SQL; dieser Dialekt hat viele Ähnlichkeiten mit der Sprache Ada.
SQL/PSM: Eine Erweiterung von SQL um eine prozedurale Sprache zur Verwendung in Stored Procedures. MySQL, MariaDB und PostgreSQL implementieren das SQL/Persistent Stored Module des Core SQL-Standards. MariaDB unterstützt auch PL/SQL.
Transact-SQL: Wird sowohl von Microsoft SQL Server als auch von Sybase Adaptive Server verwendet, der jetzt zu SAP gehört. Da sich Microsoft und SAP/Sybase von der gemeinsamen Plattform der frühen 1990er Jahre entfernt haben, haben sich auch ihre Implementierungen von Transact-SQL stark voneinander unterschieden, aber die grundlegenden Befehle sind immer noch sehr ähnlich.

Wenn du vorhast, viel mit einem einzigen Datenbanksystem zu arbeiten, solltest du dich mit den Feinheiten des von dir bevorzugten SQL-Dialekts oder der Plattform vertraut machen.

NoSQL

Es gibt viele nicht-relationale Datenbankplattformen, die auf SQL verzichten, auch bekannt als NoSQL-Datenbanken. Das sind nicht-tabellarische Datenbanken, die ganz andere Anforderungen erfüllen als relationale Datenbanken. Sie verwenden andere Datenstrukturen wie Schlüssel/Wert-Paare, Graphen und Dokumente, die bestimmte Operationen erleichtern. Ironischerweise (angesichts des Namens) bieten viele der beliebtesten NoSQL-Angebote ein gewisses Maß an Unterstützung für SQL. So lösen die Nutzer von Apache Hadoop ihre Probleme mit der Abfragesprache in der Regel mit Apache Hive, das von Facebook entwickelt wurde, oder Apache Pig, das von Yahoo entwickelt wurde; Hive unterstützt einen großen Teil des SQL-Standards, und die Abfragesprache von Pig verwendet eine SQL-ähnliche Syntax. Auch die Cassandra Query Language (CQL), die von der NoSQL-Plattform Cassandra verwendet wird, enthält eine vertraute Syntax für Abfragen, Datenmanipulation und Datendefinition.

Es mag kontraintuitiv erscheinen, aber die Realität ist, dass sowohl Open-Source- als auch kommerzielle NoSQL-Datenbankimplementierungen den Marktwert von SQL schnell zu schätzen gelernt haben. Diejenigen, die den schnellsten Weg zu einer weit verbreiteten Akzeptanz und die geringsten Reibungsverluste beim Einstieg in die Datenbank suchten, lernten, dass die Einführung von SQL ihnen den Zugang zu einer breiten Welt von Datenexperten eröffnete. Während NoSQL zunächst als "eine nicht-relationale Datenbankplattform, die kein SQL verwendet" in den Sprachgebrauch einging, wird es heute als "eine nicht-relationale Datenbankplattform, die nicht nur SQL, sondern auch andere Programmiersprachen verwendet" verstanden. SQL hat ein beeindruckendes Durchhaltevermögen, und die Fähigkeiten, die du mit diesem Buch lernst, werden deine Karriere wahrscheinlich überdauern.

Wie sagst du es?

Veteranen der verschiedenen Datenbankplattformen, die in diesem Buch behandelt werden, streiten sich gelegentlich darüber, ob SQL am besten akronymisch, wie in "S-Q-L", oder phonetisch, wie in "Sequel", ausgesprochen wird. Nach allgemeiner Erfahrung wird die Sprache und ihre Implementierungen am häufigsten mit dem Akronym bezeichnet: Die meisten Oracle-Benutzer bezeichnen PL/SQL beispielsweise als "P-L-S-Q-L" und die meisten SQL Server-Benutzer Transact-SQL als "T-S-Q-L". Wenn es sich jedoch um Eigennamen handelt, die "SQL" enthalten, nimmt es in der Regel seine phonetische Form an: Microsoft-Benutzer sagen zum Beispiel "Azure Sequel" und "Sequel Server", wenn sie von Azure SQL Database und SQL Server sprechen, und MySQL wird normalerweise "MySequel" ausgesprochen. Wenn du eine lebhafte Unterhaltung (oder einen hitzigen Streit) beginnen willst, sag einer Person, die mit Datenbanken zu tun hat, einfach, dass sie SQL falsch ausspricht - und schau zu, wie die Funken fliegen.

Get SQL in a Nutshell, 4. Auflage now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

SQL in a Nutshell, 4. Auflage by Kevin Kline, Regina O. Obe, Leo S. Hsu