Abfragen mit SELECT

Eine Abfrage fragt Daten aus einer Datenbank ab. Eine einfache SELECT-Abfrage liest die gespeicherte Tabelle, ohne sie zu ändern. SELECT benennt die anzuzeigenden Spalten und FROM die auszulesende Tabelle.

Die Textbeispiele verwenden den gewöhnlichen Gleichheitsvergleich in SQLite und PostgreSQL, der Groß- und Kleinschreibung beachtet. Einstellungen der Sortierfolge können ändern, wie Text verglichen und sortiert wird.

Zwei Tabellen zum Arbeiten

Die Tabelle employees hat diese acht Zeilen. salary ist das Jahresgehalt in Dollar; hire_date ist Text in der Form YYYY-MM-DD. NULL kennzeichnet einen fehlenden Wert.

Die Tabelle products erfasst Preise in Dollar und den Lagerbestand in Stück.

Den Aufbau der Abfrage lesen

SELECT city, first_name
FROM employees;

Die Ergebnismenge ist eine weitere Tabelle: acht Zeilen und zwei Spalten, mit city an erster Stelle. Es gibt keinen Filter, daher trägt jede beschäftigte Person eine Zeile bei. SQL garantiert keine Zeilenreihenfolge, solange du kein ORDER BY ergänzt.

SELECT * FROM products; zeigt alle Spalten in der in der Tabelle definierten Reihenfolge an. Der Stern ist beim Erkunden nützlich. Wenn du in einer gespeicherten Abfrage die Spalten benennst, bleibt das Ergebnis auf das Nötige beschränkt und eine neu hinzugefügte Tabellenspalte ändert seinen Aufbau nicht.

Die Syntax lesbar gestalten

Trenne Spalten durch Kommas, ohne ein abschließendes Komma vor FROM. Beende die Anweisung mit einem Semikolon. Bei Schlüsselwörtern spielt die Groß- und Kleinschreibung keine Rolle, sodass select funktioniert. Großbuchstaben machen Klauseln aber leicht auffindbar. Leerzeichen und Zeilenumbrüche trennen Wörter; sie ändern die Bedeutung dieser Abfrage nicht. Ein ---Kommentar reicht bis zum Ende seiner Zeile.

Namen müssen im Schema gefunden werden können. Führt frist_name zu einem Fehler wegen einer fehlenden Spalte, vergleiche die Schreibweise mit first_name. Standard-SQL verwendet doppelte Anführungszeichen für Namen, die Leerzeichen enthalten oder reservierte Wörter sind, etwa "order date". PostgreSQL wandelt Namen ohne Anführungszeichen in Kleinbuchstaben um, während "City" genau diesen großgeschriebenen Namen sucht. MySQL verwendet normalerweise Graviszeichen; doppelte Anführungszeichen kennzeichnen Namen im Modus ANSI_QUOTES. SQL Server akzeptiert auch eckige Klammern und bei eingeschaltetem QUOTED_IDENTIFIER, seiner Standardeinstellung, doppelte Anführungszeichen.

Ein wiederholter Wert in einem Abfrageergebnis ist oft nützlich. Mehrere Beschäftigte können in derselben Stadt wohnen und trotzdem braucht jede Person eine Zeile. Verwende DISTINCT, wenn die Frage nach unterschiedlichen Werten oder unterschiedlichen Kombinationen fragt.

Festlegen, was als Duplikat zählt

SELECT DISTINCT city
FROM employees;

Das Ergebnis enthält Chicago, Denver und Boston, ohne garantierte Reihenfolge. Das einfache SELECT city würde acht Zeilen zurückgeben, weil jede beschäftigte Person eine Stadt beisteuert. Mit DISTINCT wird die Anzeige auf drei unterschiedliche Werte reduziert. Alle acht Datensätze der Beschäftigten bleiben gespeichert.

Der Vergleich umfasst jede ausgewählte Spalte. Betrachte:

SELECT DISTINCT department, city
FROM employees;

Ana und Chloe steuern beide (Sales, Chicago) bei, sodass dieses Paar einmal erscheint. Emma steuert (Sales, Denver) bei, das anders ist und erhalten bleibt. Die anderen Paare sind (IT, Denver), (Marketing, Boston), (IT, Chicago), (NULL, Boston) und (Marketing, Chicago). Es gibt sieben Ergebniszeilen. Wiederholte Abteilungen bleiben erhalten, weil eine Abteilung mit einer anderen Stadt eine andere Ergebniszeile bildet.

Schreibe DISTINCT einmal direkt nach SELECT. Es gilt für die gesamte ausgewählte Zeile. Zwischen Spaltennamen, wie in SELECT department, DISTINCT city, ist es ein Syntaxfehler.

Auf die einbezogenen Spalten achten

Fügst du employee_id zu den ausgewählten Spalten hinzu, wird jede Zeile unterschiedlich. SELECT DISTINCT employee_id, city FROM employees; gibt weiterhin acht Zeilen zurück: Jede ID ist eindeutig, auch wenn sich die Stadt wiederholt. Um „In welchen Städten gibt es Beschäftigte?“ zu beantworten, wähle nur die Stadt. Für „Welche Beschäftigten wohnen in welcher Stadt?“ behalte identifizierende Spalten und erwarte wiederholte Städte.

Beim Entfernen von Duplikaten werden wiederholte NULL-Werte als Duplikate behandelt. SELECT DISTINCT department FROM employees; gibt Sales, IT, Marketing und eine NULL-Zeile zurück. Die NULL-Zeile zeigt, dass eine Abteilung fehlt; sie ist kein vierter Abteilungsname. Diese Duplikatregel unterscheidet sich von NULL = NULL, was in einem Filter unbekannt ergibt.

Textvergleiche folgen einer Sortierfolge, den Regeln der Datenbank für den Abgleich und die Anordnung von Text. Bei den gewöhnlichen Vergleichen dieser SQLite- und PostgreSQL-Beispiele, die Groß- und Kleinschreibung beachten, sind Chicago und chicago unterschiedliche Werte. Eine DISTINCT-Liste kann uneinheitliche Groß- und Kleinschreibung sichtbar machen. Das Entfernen wiederholter Anzeigen korrigiert nicht die Schreibweise in den gespeicherten Daten.

DISTINCT mit einer sortierten Auswahlliste kombinieren

SELECT DISTINCT city
FROM employees
ORDER BY city
LIMIT 2;

Zuerst verschwinden doppelte Städte. Danach werden die drei Städte sortiert. Schließlich bleiben zwei Ergebniszeilen: Boston und Chicago, in dieser Reihenfolge. Würde die Begrenzung zuerst auf die Zeilen der Beschäftigten angewendet, beantwortete das eine andere Frage.

Nimm bei einer DISTINCT-Abfrage die Sortierspalten in die SELECT-Liste auf. PostgreSQL verlangt das; SQLite erlaubt manche Abfragen, die nach einer nicht ausgewählten Spalte sortieren. Die Auswahl zwischen unterschiedlichen verborgenen Werten macht ihre Reihenfolge aber schwer deutbar. Wiederholt sich ein Ergebnis unerwartet, prüfe, welche Spalten du ausgewählt hast, bevor du entscheidest, ob DISTINCT in die Abfrage gehört.

Die WHERE-Klausel behält eine Zeile nur, wenn ihre Bedingung wahr ist. Sie folgt auf FROM und kann jede Spalte der Tabelle prüfen, auch eine Spalte, die du nicht anzeigst.

Formulierung und Operator zuordnen

<> ist die Standard-SQL-Schreibweise für „ungleich“. Die fünf hier besprochenen Datenbanken akzeptieren auch !=. Verwende für Gleichheit ein Gleichheitszeichen. SQLite akzeptiert ==, PostgreSQL lehnt diese Form aber ab.

Eine Zeile am Grenzwert verfolgen

SELECT first_name, salary
FROM employees
WHERE salary > 60000;

Ben hat 71.000, Emma 65.000 und Farid 83.000. Das sind die drei passenden Zeilen, ohne festgelegte Reihenfolge. David verdient genau 60.000. Seine Zeile erfüllt > 60000 nicht, weil „mehr als“ Gleichheit ausschließt.

Ändere nur den Operator zu >=. David kommt nun zum Ergebnis hinzu, sodass es vier Zeilen enthält. So unterscheidet sich „mindestens 60.000“ von „mehr als 60.000“. Bei einer hilfreichen Grenzwertprüfung fragst du, was mit einem Wert geschieht, der genau dem Schwellenwert entspricht; Werte weit darüber können diesen Fehler nicht aufdecken.

Bei „höchstens 20,50“ erfüllt ein Preis von 20,50 die Bedingung, ein Preis von 20,51 dagegen nicht. Gibt eine Anfrage sowohl eine Unter- als auch eine Obergrenze an, prüfe jede Grenze einzeln, bevor du die Prüfungen verknüpfst.

Numerische Werte als Zahlen schreiben

Verwende in SQL-Bedingungen nur Ziffern: 60000, ohne Tausenderkomma oder Währungszeichen. Ein Komma trennt SQL-Einträge; WHERE salary > 60,000 ist ein Syntaxfehler. Dezimalwerte werden mit Punkt geschrieben, wie in WHERE price < 20.50. Gehälter und Preise gehören in numerische Spalten, damit Vergleiche ihre numerische Größe berücksichtigen.

Text, der wie eine Zahl aussieht, folgt beim Textvergleich den Regeln für Text. Der Textwert '9' wird nach '10' einsortiert, weil sein erstes Zeichen später kommt. Das sagt etwas über Zeichen aus, nicht darüber, dass neun größer als zehn wäre. Lies den Datentyp der Spalte, bevor du einen unerwarteten Vergleich deutest.

Filtern, ohne die geprüfte Spalte anzuzeigen

SELECT first_name
FROM employees
WHERE salary < 50000;

Chloe und Grace erfüllen die Bedingung. Ihre Gehälter werden zum Prüfen der Zeilen verwendet, fehlen aber im Ergebnis. Du musst das Gehalt nicht zu SELECT hinzufügen, damit der Filter funktioniert. Beim Prüfen einer Abfrage kann es helfen, das Gehalt vorübergehend anzuzeigen, um den Grund für jede passende Zeile zu untersuchen.

Ein Gleichheitsvergleich mit einem Primärschlüssel ermöglicht das direkte Nachschlagen eines Datensatzes: WHERE employee_id = 6 findet Farid. Ein Primärschlüssel identifiziert eine Zeile, sodass dieser Gleichheitsvergleich nicht mehrere Beschäftigte mit derselben ID zurückgeben kann.

Fehlende Daten brauchen besondere Aufmerksamkeit. WHERE stock <> 0 gibt sechs Produkte zurück. Lamp Shade wird ausgelassen, weil sein bekannter Lagerbestand null ist. Bookshelf wird ebenfalls ausgelassen: Sein Lagerbestand ist NULL, sodass der Vergleich unbekannt ist und WHERE die Zeile nicht behält. Eine Ungleichheitsprüfung nimmt fehlende Werte nicht in ihr Ergebnis auf.

Text- und Datumsbedingungen brauchen Werte in einer Form, die die Datenbank interpretieren kann. Ein falsch geschriebener Wert kann stillschweigend keine Zeilen zurückgeben, während ein fehlendes Anführungszeichen dazu führen kann, dass der Wert als Spaltenname gelesen wird.

Einen Wert von einem Namen unterscheiden

SELECT first_name
FROM employees
WHERE city = 'Chicago';

Die einfachen Anführungszeichen machen 'Chicago' zu einem Textwert. Das Ergebnis enthält Ana, Chloe, Farid und Hugo. Ohne Anführungszeichen wird Chicago als Name gelesen, sodass die Datenbank nach einer Spalte mit diesem Namen sucht. Die doppelten Anführungszeichen des Standards kennzeichnen ebenfalls Namen. PostgreSQL lehnt city = "Chicago" ab, wenn keine solche Spalte existiert. Manche SQLite-Konfigurationen akzeptieren aus historischen Gründen Zeichenketten in doppelten Anführungszeichen; verwende für Werte durchgehend einfache Anführungszeichen.

Ein Apostroph innerhalb eines Werts wird verdoppelt:

SELECT first_name
FROM employees
WHERE last_name = 'O''Neill';

Das findet Hugo. Die beiden aufeinanderfolgenden einfachen Anführungszeichen stehen für einen Apostroph innerhalb des Werts; die äußeren Anführungszeichen kennzeichnen dessen Anfang und Ende. Standard-SQL verwendet keinen umgekehrten Schrägstrich als Escape-Zeichen für diesen Apostroph.

Die Vergleichsregeln prüfen

Eine Sortierfolge steuert die Gleichheit und Sortierung von Text, einschließlich der Behandlung von Groß- und Kleinschreibung und Buchstaben mit Akzenten. Bei den hier verwendeten gewöhnlichen SQLite- und PostgreSQL-Vergleichen, die Groß- und Kleinschreibung beachten, unterscheiden sich 'Chicago' und 'chicago'. WHERE city = 'chicago' gibt keine Zeilen zurück. MySQL und SQL Server verwenden häufig Sortierfolgen, die Groß- und Kleinschreibung ignorieren, sodass ihre üblichen Einstellungen beide Schreibweisen abgleichen können.

Auch Bereichsvergleiche von Text folgen der Sortierfolge. Bei diesen Namen gibt WHERE last_name < 'M' Brown, Carter, Haddad, Kim und Lopez zurück. Werte werden von links verglichen. Ein längerer Wert, der mit denselben Zeichen beginnt, kommt nach seinem Präfix: 'Martin' steht nach 'M'. Eine Grenze bei 'M' ist nicht dasselbe wie „alle Namen, die mit M beginnen“.

Das Jahr zuerst setzen

Die Beispielspalte hire_date speichert vollständige Datumswerte als Text: Jahr, Monat, dann Tag, jeweils mit fester Länge. Dadurch stimmt die Textreihenfolge mit der Kalenderreihenfolge überein.

SELECT first_name, hire_date
FROM employees
WHERE hire_date >= '2022-01-01';

Chloe, Grace und Hugo erfüllen die Bedingung. PostgreSQL hat auch einen echten DATE-Typ, der dieses Literal akzeptiert. Seine typisierte Standardschreibweise ist DATE '2022-01-01'; SQLite verwendet diese Syntax für typisierte Literale nicht.

Eine lokale Datumszeichenkette wie '03/04/2024' ist in einer Datumsspalte mehrdeutig, weil sie je nach Einstellung den 4. März oder den 3. April bedeuten kann. Als Text gespeicherte Datumswerte mit dem Monat an erster Stelle werden zuerst nach dem Monat und dann nach dem Jahr verglichen. So wird '12/01/2021' nach '03/15/2024' einsortiert, obwohl das erste Kalenderdatum früher liegt.

Die vollständige Datumsgrenze übersetzen

„Nach 2022 eingestellt“ bedeutet ab '2023-01-01'. Ein Textvergleich mit '2022' lässt dagegen auch das Einstellungsdatum '2022-08-05' von Hugo zu: Der längere Text wird nach dem übereinstimmenden Präfix einsortiert.

Enthält eine Spalte Uhrzeiten, wählt ein Gleichheitsvergleich mit einem Datum allein nicht jede Uhrzeit an diesem Tag aus. Um den 31. März 2024 einzuschließen, verwende ordered_at >= '2024-03-31' AND ordered_at < '2024-04-01'. Das behält alle Uhrzeiten vom Beginn des 31. März bis zum Beginn des 1. April, ohne diesen einzuschließen.

Eine Zeile muss möglicherweise mehrere Prüfungen bestehen. AND verlangt, dass beide Bedingungen wahr sind. OR verlangt, dass mindestens eine wahr ist. NOT kehrt wahr und falsch um; ist eine Bedingung wegen NULL unbekannt, lässt NOT sie unbekannt.

Entscheiden, ob beide Prüfungen erfüllt sein müssen

SELECT first_name
FROM employees
WHERE department = 'Sales' AND city = 'Chicago';

Ana und Chloe bestehen beide Prüfungen. Emma arbeitet in Sales, wohnt aber in Denver und erfüllt dieses AND daher nicht. Ersetzt man AND durch OR, kommen auch Emma, Farid und Hugo hinzu: Die fünf passenden Beschäftigten erfüllen eine oder beide Prüfungen.

Eine zusätzliche AND-Bedingung kann das Ergebnis gleich lassen oder verkleinern. Eine zusätzliche OR-Bedingung kann es gleich lassen oder vergrößern. Das ermöglicht dir eine schnelle Prüfung, wenn du einen Filter schrittweise aufbaust.

Jeder Vergleich muss vollständig sein. Schreibe department = 'IT' OR department = 'Marketing' und wiederhole dabei Spalte und Operator. department = 'IT' OR 'Marketing' drückt den zweiten Vergleich nicht aus. PostgreSQL lehnt dies ab; SQLite behandelt den Text allein als falsch und gibt nur Beschäftigte aus IT zurück. Schreibe ebenso salary > 50000 AND salary < 70000, mit salary auf beiden Seiten von AND.

Gruppen von Alternativen übersetzen

„Beschäftigte in Boston und Denver“ fragt gewöhnlich nach Personen in einer der beiden Städte. Jede Zeile hat eine Stadt, verwende daher city = 'Boston' OR city = 'Denver'. Das gibt Ben, David, Emma und Grace zurück. Ein AND zwischen diesen Gleichheitsvergleichen verlangt, dass ein Stadtwert beide Orte zugleich ist, und gibt keine Zeilen zurück.

Werden Operatoren gemischt, wird NOT vor AND und AND vor OR ausgewertet. Ohne Klammern:

WHERE department = 'Sales'
   OR department = 'Marketing' AND city = 'Chicago'

Das bedeutet Beschäftigte aus Sales an beliebigen Orten und zusätzlich Beschäftigte aus Marketing in Chicago. Emma erfüllt die Bedingung, weil der Vergleich mit Sales ausreicht. Um beide Abteilungen auf Chicago zu beschränken, gruppiere die Alternativen:

SELECT first_name
FROM employees
WHERE (department = 'Sales' OR department = 'Marketing')
  AND city = 'Chicago';

Nun erfüllen Ana, Chloe und Hugo die Bedingung. Die Klammern stellen beide Abteilungsoptionen unter eine gemeinsame Stadtbedingung. Verwende sie, um einen gemischten AND/OR-Filter verständlich zu machen, auch wenn die Standardreihenfolge bereits richtig wäre.

Eine ganze Gruppe umkehren

NOT (city = 'Chicago' OR city = 'Denver') gibt David und Grace in Boston zurück. Keine der beiden aufgeführten Städte ist erlaubt. Für diese Werte ist das gleichbedeutend mit city <> 'Chicago' AND city <> 'Denver'.

OR zwischen diesen beiden Ungleichheitsprüfungen zu verwenden, ist eine häufige Falle. Eine Chicago-Zeile unterscheidet sich von Denver und eine Denver-Zeile von Chicago. Alle Beschäftigten mit einer erfassten Stadt bestehen mindestens eine Prüfung, sodass OR keine der beiden Städte ausschließt.

Baue eine komplexe Bedingung Stück für Stück auf. Prüfe die Zeilen nach der ersten Prüfung und dann nach dem Hinzufügen der nächsten. Du kannst die beiden Seiten eines AND oder eines OR vertauschen, ohne die Antwort zu ändern. Wähle die Anordnung, bei der die Gruppen am leichtesten zu lesen sind.

Verwende IN, wenn eine Spalte einem beliebigen Wert einer Liste entsprechen darf. Es verkürzt eine Gruppe von Gleichheitsvergleichen, die durch OR verbunden sind, und behält dabei ihre Bedeutung.

Eine Liste von Alternativen erstellen

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing');

Ben, David, Farid und Hugo erfüllen die Bedingung. Jede dieser Personen hat einen der beiden Abteilungswerte. Dieselbe Prüfung ließe sich als department = 'IT' OR department = 'Marketing' schreiben.

Setze Listeneinträge in Klammern und trenne sie durch Kommas. Setze Text in einfache Anführungszeichen; numerische Werte bleiben ohne Anführungszeichen. Zum Beispiel wählt employee_id IN (2, 4, 6) Ben, David und Farid aus. Die Reihenfolge der Listeneinträge sortiert das Ergebnis nicht. Ein wiederholter Eintrag wiederholt keine passende Zeile: IN (6, 2, 2, 4) wählt dieselben Datensätze aus. Verwende ORDER BY, wenn du eine Ergebnisreihenfolge brauchst.

IN gleicht ganze Werte nach denselben Vergleichsregeln wie ein Gleichheitsvergleich ab. city IN ('Chi') trifft nicht auf Chicago zu. Auch city IN ('chicago') trifft bei den hier verwendeten gewöhnlichen Vergleichen, die Groß- und Kleinschreibung beachten, nicht darauf zu. Für die Suche nach einem Teilwert brauchst du LIKE; die Behandlung der Groß- und Kleinschreibung hängt von der Sortierfolge ab.

Eine weitere Regel auf jede Auswahl anwenden

SELECT first_name
FROM employees
WHERE department IN ('IT', 'Marketing')
  AND city = 'Chicago';

Farid und Hugo erfüllen die Bedingung. IN ist eine Bedingung, sodass AND die Stadtprüfung auf die gesamte Abteilungsauswahl anwendet. Setze in der ausgeschriebenen OR-Variante Klammern um die beiden Abteilungsvergleiche. Ohne sie lässt department = 'IT' OR department = 'Marketing' AND city = 'Chicago' auch Ben zu, weil AND stärker bindet und die Stadtregel nur für Marketing gilt.

Die aufgeführten Werte ausschließen

WHERE city NOT IN ('Chicago', 'Denver') gibt David und Grace zurück. Eine erfasste Stadt erfüllt die Bedingung nur, wenn sie sich von beiden Einträgen unterscheidet. Diese Form ist für mehrere Ausschlüsse nützlich und vermeidet den Fehler, Ungleichheitsbedingungen mit OR zu verbinden.

Fehlende Werte erfüllen keine der beiden Formen. Grace hat die Abteilung NULL, sodass department NOT IN ('Sales') sie nicht einschließt. Die Datenbank kann nicht feststellen, dass sich die fehlende Abteilung von Sales unterscheidet. Um auch Beschäftigte ohne zugewiesene Abteilung einzuschließen, schreibe department NOT IN ('Sales') OR department IS NULL.

Ein NULL innerhalb einer NOT-IN-Liste verursacht ein umfassenderes Problem. department NOT IN ('Sales', NULL) verlangt sowohl department <> 'Sales' als auch department <> NULL. Der zweite Vergleich ist immer unbekannt, sodass die kombinierte Prüfung nie wahr ist und WHERE keine Zeilen zurückgibt. Halte Prüfungen auf fehlende Werte von der Werteliste getrennt.

Bei IN ist eine tatsächliche Übereinstimmung weiterhin erfolgreich, auch wenn ein anderer Listeneintrag NULL ist. department IN ('Sales', NULL) behält die drei Beschäftigten aus Sales, nimmt Grace aber nicht hinzu. Verwende IS NULL, um fehlende Werte ausdrücklich anzufordern.

Eine gewöhnliche SQL-IN-Liste braucht mindestens einen Eintrag. PostgreSQL lehnt IN () ab; SQLite akzeptiert es als falsch. Erstellt ein Programm eine Liste aus der Auswahl von Nutzern, behandle eine leere Liste vor dem Absenden der Abfrage, damit das Verhalten über Datenbanken hinweg bewusst festgelegt ist.

BETWEEN prüft einen Bereich, wobei beide Grenzen eingeschlossen sind. Verwende es, wenn „von“ und „bis“ die genannten Grenzwerte einschließen; verwende ausdrückliche Vergleiche, wenn eine der Grenzen ausgeschlossen werden muss.

Die beiden Grenzen prüfen

SELECT name, price
FROM products
WHERE price BETWEEN 15.50 AND 89.00;

Desk Lamp, Floor Lamp, Lamp Shade und Desk Organizer erfüllen die Bedingung. Floor Lamp kostet genau 89,00 und Lamp Shade genau 15,50, sodass beide erhalten bleiben. Die Bedingung bedeutet price >= 15.50 AND price <= 89.00.

Setze den kleineren Wert zuerst. price BETWEEN 89.00 AND 15.50 fragt nach einem Preis von mindestens 89,00 und höchstens 15,50. Die Syntax ist gültig, aber es gibt keine Übereinstimmungen. Ein gewöhnliches BETWEEN ordnet die Bereichsgrenzen nicht für dich um. PostgreSQL bietet dafür BETWEEN SYMMETRIC an, verwende aber für eine auch mit SQLite genutzte Abfrage die Form mit dem kleineren Wert zuerst.

Für „mehr als 15,50 und weniger als 89,00“ schreibe price > 15.50 AND price < 89.00. Nur Desk Lamp und Desk Organizer erfüllen die Bedingung. Dieser Unterschied betrifft die Bereichsgrenzen der Frage, nicht die Anzeige des Ergebnisses.

Außerhalb eines Bereichs

price NOT BETWEEN 20 AND 100 bedeutet price < 20 OR price > 100. Es gibt Lamp Shade, Office Chair, Standing Desk, Desk Organizer, Bookshelf und Paper Tray zurück. Werte von genau 20 oder 100 lägen innerhalb des ursprünglichen Bereichs und erfüllten NOT BETWEEN nicht.

Ein fehlender geprüfter Wert ergibt bei beiden Prüfungen unbekannt. Für den Lagerbestand wählt BETWEEN 5 AND 40 fünf Produkte aus und NOT BETWEEN zwei: Lamp Shade mit 0 und Desk Organizer mit 60. Bookshelf hat den Lagerbestand NULL und gehört zu keinem der beiden Ergebnisse. Ein Bereich und seine Verneinung müssen daher nicht jede gespeicherte Zeile abdecken.

Datumswerte und Uhrzeiten

Vollständige Datumszeichenketten in der Reihenfolge YYYY-MM-DD erlauben Datumsbereiche. hire_date BETWEEN '2020-01-01' AND '2022-12-31' wählt Ben, David und Hugo aus und deckt in dieser Spalte, die nur Datumswerte enthält, alle drei Kalenderjahre ab.

Eine Spalte mit Uhrzeiten braucht für einen ganzen Monat eine andere obere Grenze. Eine Bereichsgrenze, die nur ein Datum enthält, bedeutet in einer Zeitstempelspalte Mitternacht zu Beginn dieses Tages. Als Text wird selbst '2024-03-31 00:00:00' nach dem kürzeren Präfix '2024-03-31' einsortiert. Um alle Uhrzeiten im März einzuschließen, verwende:

WHERE ordered_at >= '2024-03-01'
  AND ordered_at < '2024-04-01'

Das schließt den Beginn des März ein und endet unmittelbar vor dem April, ohne den letzten Sekundenbruchteil am 31. März erraten zu müssen.

Textbereiche und die zwei Funktionen von AND

Bereichsgrenzen bei Text sind vollständige Werte. last_name BETWEEN 'A' AND 'C' schließt Brown ein, aber Carter aus, weil Carter nach seinem Präfix C einsortiert wird. Nach diesen Textregeln deckt last_name >= 'A' AND last_name < 'D' Namen ab, die mit A, B oder C beginnen, und gibt Brown und Carter zurück.

In price BETWEEN 10 AND 100 AND category = 'Lighting' trennt das erste AND die Bereichsgrenzen; das zweite verbindet die Bereichsprüfung mit der Kategorieprüfung. Die passenden Produkte sind Desk Lamp, Floor Lamp und Lamp Shade. Zeilenumbrüche können die beiden Funktionen leichter erkennbar machen.

LIKE gleicht Text mit einem Muster ab. Verwende es, um nach einem Anfang, einem Ende oder einem Textteil zu suchen, wenn ein Gleichheitsvergleich einen vollständig übereinstimmenden Wert verlangen würde.

Die Platzhalter setzen

Das Muster muss auf den ganzen Wert passen. % kann null oder mehr Zeichen darstellen, einschließlich Leerzeichen. In '%Lamp%' kann jedes der beiden Prozentzeichen auch auf nichts passen, sodass der Text mit Lamp beginnen oder enden und es auch in der Mitte enthalten kann.

_ steht für genau ein Zeichen. last_name LIKE '_im' findet Kim. Vier Unterstriche in first_name LIKE '____' finden Emma und Hugo, die Vornamen mit genau vier Buchstaben. Der Unterstrich steht nicht für ein optionales Zeichen.

SELECT first_name, phone
FROM employees
WHERE phone LIKE '312-%';

Ana, Chloe und Farid erfüllen die Bedingung, weil der erfasste Text ihrer Telefonnummern mit 312- beginnt. Das Prozentzeichen deckt alle übrigen Zeichen ab.

Operator und Regel für Groß- und Kleinschreibung wählen

Platzhalter gehören zu LIKE-Mustern. name = '%Lamp%' sucht nach tatsächlichen Prozentzeichen und gibt hier keine Produkte zurück. Die Platzhalter * und ? aus der Dateisuche haben bei LIKE keine besondere Bedeutung; name LIKE 'Desk*' sucht nach einem tatsächlichen Sternchen nach Desk.

LIKE in SQLite ignoriert normalerweise die Groß- und Kleinschreibung bei den ASCII-Buchstaben A bis Z, während das gewöhnliche LIKE in PostgreSQL sie beachtet. name LIKE '%desk%' findet daher in SQLite Desk Lamp, Standing Desk und Desk Organizer, in PostgreSQL bei einer Sortierfolge, die Groß- und Kleinschreibung beachtet, dagegen keine Zeilen. PostgreSQL bietet außerdem ILIKE an, das Groß- und Kleinschreibung ignoriert. Das Verhalten von MySQL folgt der Sortierfolge.

Für die hier verwendeten ASCII-Produktnamen liefert LOWER(name) LIKE '%desk%' in SQLite und PostgreSQL dieselben Treffer: LOWER wandelt den Namen vor dem Abgleich in Kleinbuchstaben um. Die Umwandlung der Groß- und Kleinschreibung für andere Schriftsysteme hängt von Datenbank- und Sprachregeln ab. Auch der Gleichheitsvergleich in SQLite unterscheidet sich von seinem LIKE: city = 'chicago' findet Chicago bei der standardmäßigen binären Sortierfolge nicht, obwohl city LIKE 'chicago' es findet.

Nach einem tatsächlichen Platzhalterzeichen suchen

Um nach einem tatsächlichen Unterstrich zu suchen, wähle ein Escape-Zeichen:

WHERE code LIKE 'SPRING!_%' ESCAPE '!'

In einer Tabelle mit Rabattcodes trifft dies auf 'SPRING_10', aber nicht auf 'SPRINGS10' zu. Das !_ steht für einen tatsächlichen Unterstrich; das letzte % steht weiterhin für eine Zeichenfolge. Verwende denselben Ansatz mit !% für ein tatsächliches Prozentzeichen. Ein ausdrücklich geschriebenes ESCAPE vermeidet die Abhängigkeit von den Standardeinstellungen der Datenbank; PostgreSQL verwendet normalerweise einen umgekehrten Schrägstrich und SQLite hat kein standardmäßiges Escape-Zeichen.

Verneinung und Suchumfang

name NOT LIKE '%Lamp%' gibt die anderen fünf Produkte zurück. Fehlender Text erfüllt weder LIKE noch NOT LIKE. Von den Telefonnummern der Beschäftigten passen drei auf '312-%', zwei erfasste Telefonnummern passen nicht und die drei NULL-Telefonnummern erscheinen in keinem der beiden Ergebnisse.

Ein führendes % gibt einem gewöhnlichen Index keinen festen Anfangstext, auf den er die Suche eingrenzen kann, sodass möglicherweise ein großer Teil der Tabelle durchsucht wird. Ein fester Anfang wie 'Desk%' kann einem geeigneten Index helfen. Verwende für Datumswerte Datumsbereiche: LIKE funktioniert bei diesen Textdatumswerten, aber PostgreSQL verlangt eine Umwandlung, bevor LIKE auf eine echte DATE-Spalte angewendet wird.

NULL kennzeichnet einen fehlenden Wert: Ein Wert kann unbekannt, nicht erfasst oder nicht anwendbar sein. Er unterscheidet sich von einer bekannten Null oder einem bekannten Text ohne Zeichen.

Verstehen, was ein fehlender Wert bedeutet

Lamp Shade hat stock = 0. Die erfasste Stückzahl ist null, das Produkt ist also nicht vorrätig. Bookshelf hat stock NULL: Die Stückzahl wurde nicht erfasst. Die Datenbank kann dir weder sagen, dass null Stück vorhanden sind, noch eine andere Anzahl nennen.

Der Unterschied verändert, welche Frage du beantworten kannst:

Eine leer aussehende Zelle in einem Abfragewerkzeug reicht nicht aus, um diese Zustände zu unterscheiden. Manche Werkzeuge zeigen NULL als leere Zelle an, andere schreiben NULL. Prüfe den gespeicherten Wert direkt.

Prüfungen auf fehlende Werte verwenden

SELECT first_name
FROM employees
WHERE phone IS NULL;

Für Ben, Emma und Hugo ist keine Telefonnummer erfasst. IS NULL ergibt für ihre fehlenden Werte wahr. Um die fünf Beschäftigten mit erfasster Telefonnummer zu finden, verwende phone IS NOT NULL: Ana, Chloe, David, Farid und Grace.

Schreibe nicht phone = NULL, um fehlende Telefonnummern zu finden. Ein gewöhnlicher Vergleich mit NULL ergibt unbekannt, selbst wenn beide Seiten NULL sind. WHERE behält nur wahre Zeilen, sodass = NULL keine zurückgibt. <> NULL hat dasselbe Problem. IS NULL prüft auf die Kennzeichnung für einen fehlenden Wert und ergibt für diese Werte einzelner Spalten eindeutig wahr oder falsch.

Die Form NOT phone IS NULL findet in SQLite und PostgreSQL ebenfalls vorhandene Telefonnummern, aber bei phone IS NOT NULL ist die beabsichtigte Prüfung leichter zu lesen.

Drei Arten von Text unterscheiden

SQLite, PostgreSQL, MySQL und SQL Server unterscheiden eine leere Zeichenkette von NULL. phone = '' würde leere Zeichenketten finden, nicht die fehlenden Telefonnummern von Ben, Emma oder Hugo. Kann eine Spalte beides enthalten, verwende phone IS NULL OR phone = '', um beide Zustände zu finden. Oracle behandelt einen leeren Textwert als NULL, sodass sich dieser Unterschied beim Wechsel der Datenbank ändert.

Formulierung und Schema anwenden

„Fehlend“, „nicht erfasst“ und „nicht zugewiesen“ weisen auf IS NULL hin. department IS NULL findet Grace. Ihre fehlende Abteilung bedeutet weder, dass der Abteilungstext das Wort 'NULL' ist, noch lässt sich daraus ermitteln, zu welcher Abteilung sie gehört.

Die Tabellendefinition kann eine Spalte als NOT NULL kennzeichnen. Das bedeutet, dass eine gespeicherte Zeile in dieser Spalte kein NULL enthalten kann. Eine IS-NULL-Abfrage auf einer solchen Spalte gibt keine Zeilen zurück. Prüfe diese Regel beim Lesen eines Schemas: Spalten, die fehlende Daten erlauben, brauchen besondere Aufmerksamkeit, wenn du Ausschlüsse erstellst oder Bedingungen verknüpfst.

Eine Bedingung kann in SQL wahr, falsch oder unbekannt sein. Fehlende Werte machen den dritten Zustand nötig: Ohne eine erfasste Stückzahl kann eine Datenbank nicht feststellen, ob diese über einem Schwellenwert liegt.

Eine Bedingung und ihr Gegenteil

Für Bookshelf ist stock > 10 unbekannt, weil der Lagerbestand NULL ist. Dasselbe gilt für stock <= 10. WHERE behält nur wahre Bedingungen und lässt sowohl falsche als auch unbekannte aus.

In der Produkttabelle gibt stock > 10 vier Zeilen zurück und stock <= 10 drei. Zusammen erfassen sie sieben der acht Produkte. Bookshelf fehlt in beiden Ergebnissen. NOT stellt die Zeile nicht wieder her: NOT unbekannt ist unbekannt, sodass NOT (stock > 10) weiterhin nur die drei bekannten Stückzahlen von höchstens 10 auswählt.

Das unterscheidet sich von einem Wert, der eine Bedingung nicht erfüllt. Die bekannte Null von Lamp Shade macht stock > 10 falsch, sodass NOT den Wahrheitswert in wahr umkehrt. Eine fehlende Stückzahl liefert keinen solchen eindeutigen Vergleich, den man umkehren könnte.

Unbekannt mit einer weiteren Prüfung verknüpfen

Bookshelf kostet 120,00. In stock > 10 OR price > 100 ist die Preisbedingung wahr. OR braucht nur einen wahren Teil, sodass die Zeile erhalten bleibt, obwohl der Vergleich des Lagerbestands unbekannt ist. In stock > 10 AND price > 100 bleibt die Lagerbedingung ungeklärt, sodass das Ergebnis unbekannt ist und die Zeile ausgelassen wird.

Fehlende Werte bewusst einschließen

SELECT first_name
FROM employees
WHERE department <> 'Sales'
   OR department IS NULL;

Das gibt Ben, David, Farid, Hugo und Grace zurück. Der Vergleich allein würde vier zurückgeben und Grace auslassen. Der IS-NULL-Zweig schließt Beschäftigte ohne zugewiesene Abteilung ausdrücklich ein. Ob solche Beschäftigten zu „außerhalb von Sales“ gehören, ist eine Frage der beabsichtigten Antwort; die Abfrage muss diese Entscheidung ausdrücken.

Ein NULL-Wert in einer NOT-IN-Liste kann das gesamte Ergebnis verhindern. department NOT IN ('Sales', NULL) bedeutet, dass sich die Abteilung von Sales und von NULL unterscheiden muss. Der zweite Vergleich ist für jede Zeile unbekannt, sodass die vollständige Bedingung nie wahr ist. IN behält tatsächliche Übereinstimmungen weiterhin: department IN ('Sales', NULL) wählt die drei Beschäftigten aus Sales aus, findet Grace aber nicht.

Ein fehlender geprüfter Wert ergibt auch bei LIKE und einem gewöhnlichen BETWEEN-Bereich unbekannt. IS NULL und IS NOT NULL liefern für diese einzelnen Spalten eindeutige Antworten. Prüfe fehlende Werte mit diesen Tests gesondert, wenn eine Zeilenanzahl überraschend erscheint.

Wissen, wann NULL-Werte gruppiert werden

NULL = NULL bleibt unbekannt; von zwei fehlenden Telefonnummern weiß man nicht, ob sie dieselbe Nummer sind. DISTINCT behandelt wiederholte fehlende Werte dagegen als Duplikate, und ORDER BY platziert sie zusammen. Für einen Vergleich, der zwei NULL-Werte bewusst als gleich behandelt, bieten SQLite und PostgreSQL auch IS NOT DISTINCT FROM an.

ORDER BY legt die Reihenfolge der Ergebniszeilen fest. Ohne ORDER BY verspricht SQL nicht, welche Zeile zuerst erscheint, selbst wenn eine kleine Tabelle scheinbar jedes Mal dieselbe Reihenfolge zurückgibt.

Die Richtung wählen

ASC ist die Voreinstellung. ORDER BY salary und ORDER BY salary ASC verlangen dieselbe Richtung. „Höchstes Gehalt zuerst“ verlangt ORDER BY salary DESC.

SELECT first_name, salary
FROM employees
ORDER BY salary DESC;

Lies das Ergebnis vom höchsten zum niedrigsten Wert: Farid 83.000, Ben 71.000, Emma 65.000, David 60.000, Hugo 58.000, Ana 52.000, Chloe 48.000 und Grace 45.000. Die Datenbank ordnet die Ergebniszeilen neu; diese Abfrage ändert die gespeicherte Tabelle nicht.

Vor dem Sortieren filtern

SELECT name, price
FROM products
WHERE category = 'Lighting'
ORDER BY price;

Nur die drei Lighting-Zeilen gelangen in dieses Ergebnis. Ihre aufsteigenden Preise ergeben Lamp Shade 15,50, Desk Lamp 24,99 und dann Floor Lamp 89,00. ORDER BY steht in der Anweisung nach WHERE. Die Umkehrung dieser Klauseln ist ein Syntaxfehler.

Die Sortierspalte muss nicht angezeigt werden. SELECT first_name FROM employees ORDER BY salary DESC; liefert dieselbe Namensreihenfolge, ohne Gehälter anzuzeigen. PostgreSQL schränkt dies bei DISTINCT ein: Eine DISTINCT-Abfrage muss ihre Sortierspalten auswählen.

Den gespeicherten Datentyp lesen

Numerische Spalten werden nach numerischer Größe sortiert. Textspalten werden nach Zeichen entsprechend ihrer Sortierfolge sortiert. Die Textwerte '10', '9' und '100' werden bei gewöhnlicher Zeichenreihenfolge als '10', '100', '9' sortiert. Das ist keine korrekte numerische Rangfolge. Prüfe daher den Spaltentyp, wenn Beträge falsch angeordnet erscheinen.

Die Beispielwerte von hire_date sind vollständige Textdatumswerte fester Länge mit dem Jahr an erster Stelle. ORDER BY hire_date beginnt mit Farid am 2017-09-12 und endet mit Grace am 2024-02-19. DESC kehrt dies um, sodass die neuesten Einstellungen zuerst kommen. Textdatumswerte mit dem Monat an erster Stelle wie MM/DD/YYYY werden zuerst nach Monat und dann nach Jahr verglichen und können über mehrere Jahre hinweg keine zuverlässige Kalenderreihenfolge ergeben.

Die Textreihenfolge hängt von der Sortierfolge ab

Die standardmäßige binäre Sortierfolge von SQLite setzt ASCII-Großbuchstaben vor Kleinbuchstaben. Nach dieser Regel steht 'Zebra' vor 'apple' und 'é' kommt nach 'z'. Viele PostgreSQL-Datenbanken verwenden sprachabhängige Sortierfolgen, die eine andere Reihenfolge ergeben. Einheitliche Groß- und Kleinschreibung hilft, aber die Vergleichsregeln der Datenbank entscheiden weiterhin über die Reihenfolge von Zeichen mit Akzenten und anderen Zeichen.

Verwende Spaltennamen für eine klare Sortierangabe. ORDER BY 2 DESC bezeichnet den zweiten Eintrag in der SELECT-Liste, sodass das Verschieben von Spalten die Sortierung stillschweigend ändern kann. ORDER BY 'salary' bezeichnet eine Textkonstante, nicht die Gehaltsspalte: SQLite liefert damit keine sinnvolle Sortierung und PostgreSQL lehnt es ab. Schreibe ORDER BY salary.

Eine zweite Sortierspalte ist nur wichtig, wenn Zeilen in der ersten gleiche Werte haben. Stell dir eine sortierte Personalliste vor: Gruppiere zuerst nach Stadt und ordne dann die Namen innerhalb jeder Stadt.

Den Sortierspalten von links nach rechts folgen

SELECT last_name, city
FROM employees
ORDER BY city, last_name;

Das Ergebnis beginnt mit Kim und Okafor in Boston. Dann folgen Haddad, Lopez, Nguyen und O'Neill in Chicago. Brown und Carter in Denver stehen zuletzt. last_name konkurriert nicht mit city; der Nachname entscheidet nur innerhalb derselben Stadt über die Reihenfolge.

Eine Umkehrung der Spalten ändert die Hauptreihenfolge. ORDER BY last_name, city sortiert hauptsächlich nach Nachnamen und zieht die Stadt nur bei gleichen Nachnamen heran. Verwende eine ORDER-BY-Klausel mit Kommas zwischen den Sortierspalten. Eine zweite ORDER-BY-Klausel ist ungültig.

Jeder Spalte ihre Richtung geben

ORDER BY department, salary DESC bedeutet Abteilung aufsteigend, dann Gehalt innerhalb jeder Abteilung absteigend. DESC gehört nur zu salary. Um beide absteigend zu sortieren, schreibe department DESC, salary DESC.

Bei der standardmäßigen NULL-Sortierung von SQLite setzt die erste Form die fehlende Abteilung von Grace an den Anfang. IT folgt mit Farid und dann Ben; bei Marketing steht David vor Hugo; bei Sales folgen Emma, Ana und dann Chloe. Du liest eine Hierarchie von Vergleichen und sortierst nicht zuerst jede Zeile nach Gehalt, um diese Reihenfolge dann zu ignorieren.

Gleiche Werte mit einem eindeutigen Wert auflösen

Zeilen, die in allen Sortierspalten gleiche Werte haben, können in beliebiger Reihenfolge erscheinen. ORDER BY city legt nicht fest, welche beschäftigte Person in Chicago zuerst kommt. Eine eindeutige Sortierreihenfolge ergänzt als letzte Spalte eine, die jede Zeile eindeutig identifiziert:

SELECT first_name, city
FROM employees
ORDER BY city, employee_id;

Die IDs lösen alle gleichen Stadtwerte auf. Bei unveränderten Daten sorgt das dafür, dass ein späteres LIMIT oder eine Seite einen wiederholbaren Teil der sortierten Liste auswählt. Ein eindeutiges nachrangiges Sortierkriterium legt fest, welche Zeilen an einer Grenze erscheinen; es schließt keine zusätzlichen Zeilen mit gleichen Werten ein.

Fehlende Werte bewusst platzieren

Die Voreinstellungen der Datenbanken unterscheiden sich:

Daher setzt die Abteilungsabfrage Grace bei den PostgreSQL-Voreinstellungen ans Ende, obwohl sie in SQLite zuerst steht. Dieser Unterschied ist unabhängig von der Sortierrichtung des Gehalts.

SELECT first_name, department, salary
FROM employees
ORDER BY department NULLS LAST, salary DESC;

SQLite ab Version 3.30, PostgreSQL und Oracle unterstützen NULLS FIRST und NULLS LAST. Hier setzen sie Grace hinter alle erfassten Abteilungen und erhalten dabei die Gehaltsreihenfolge innerhalb jeder Abteilung. MySQL und SQL Server akzeptieren diese Klauseln nicht.

Übersetze eine gewünschte Hierarchie in derselben Reihenfolge, in der sie genannt wird: „nach Abteilung, innerhalb jeder Abteilung das höchste Gehalt zuerst“ ergibt department, salary DESC. „Alphabetisch nach Nachnamen, dann nach Vornamen“ ergibt last_name, first_name. Ergänze eine ID zuletzt, wenn du bei Personen mit identischen Namen eine wiederholbare Reihenfolge brauchst.

LIMIT behält höchstens eine gewählte Anzahl von Ergebniszeilen. Es entscheidet nicht, welche Zeilen zuerst stehen sollen. Verwende ORDER BY, um einer Auswahlliste eine Bedeutung wie höchstes Gehalt, neueste oder günstigste zu geben.

Sortieren, dann begrenzen

SELECT first_name, salary
FROM employees
ORDER BY salary DESC
LIMIT 3;

Die sortierten Gehälter beginnen mit Farid 83.000, Ben 71.000 und Emma 65.000, sodass diese drei Zeilen erhalten bleiben. Ohne ORDER BY gibt LIMIT 3 irgendwelche drei Zeilen zurück, ohne zu garantieren, dass sie die höchsten Gehälter enthalten.

WHERE wirkt vor der Begrenzung. WHERE city = 'Boston' ORDER BY salary DESC LIMIT 5 gibt nur David und Grace zurück, weil nur zwei Beschäftigte die Bedingung erfüllen. LIMIT ist eine Obergrenze und keine Aufforderung, zusätzliche Zeilen zu erfinden. LIMIT 0 gibt keine zurück.

Zeilen für eine spätere Seite überspringen

OFFSET überspringt Zeilen, bevor LIMIT die zurückzugebenden Zeilen zählt. ORDER BY salary DESC LIMIT 3 OFFSET 3 überspringt Farid, Ben und Emma und gibt dann David, Hugo und Ana zurück: die Positionen vier bis sechs.

Für Seite k mit n Zeilen pro Seite überspringst du (k − 1) × n Zeilen. Seite drei bei drei Zeilen pro Seite verwendet LIMIT 3 OFFSET 6. Nur Chloe und Grace bleiben übrig. Die erste Seite hat den Versatz null, nicht eins.

„Zweite Zeile“ und „zweiter unterschiedlicher Wert“ sind verschiedene Anfragen. ORDER BY salary DESC LIMIT 1 OFFSET 1 gibt hier Ben mit 71.000 zurück. Hätten zwei Beschäftigte dasselbe höchste Gehalt, würde diese Abfrage eine weitere Person mit dem höchsten Gehalt zurückgeben. Um das zweite unterschiedliche Gehalt zu finden, wähle vor dem Sortieren und Überspringen DISTINCT salary aus.

Die Auswahl an der Grenze festlegen

ORDER BY city LIMIT 3 schließt die beiden Beschäftigten aus Boston und eine Person aus Chicago ein, legt aber nicht fest, welche Person aus Chicago. ORDER BY city, employee_id LIMIT 3 wählt David, Grace und Ana aus. Die eindeutige ID legt die Auswahl an der Grenze fest.

Um alle Zeilen mit demselben letzten Sortierwert zu behalten, unterstützen PostgreSQL ab Version 13 und Oracle FETCH FIRST 3 ROWS WITH TIES. Mit ORDER BY city bleiben sechs Zeilen erhalten: beide Boston-Zeilen und alle vier Chicago-Zeilen. Enthält ORDER BY auch eine eindeutige ID, können Zeilen nicht im vollständigen Sortierschlüssel übereinstimmen.

Die Syntax der Datenbank erkennen

Standard-SQL verwendet OFFSET und FETCH, nicht LIMIT. PostgreSQL und Oracle akzeptieren OFFSET 3 ROWS FETCH FIRST 3 ROWS ONLY. SQL Server verwendet ORDER BY salary DESC OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY; für diese Form der Seiteneinteilung ist ORDER BY erforderlich.

SQLite und MySQL akzeptieren auch LIMIT 6, 3, mit dem Versatz an erster Stelle. Bevorzuge LIMIT 3 OFFSET 6, damit die Rollen ausdrücklich erkennbar sind. Bei der Seiteneinteilung wird für jede Seite erneut eine Abfrage ausgeführt. Eine eindeutige Sortierreihenfolge hält die Seiten konsistent, solange die Daten unverändert bleiben; Einfügungen oder Löschungen zwischen Anfragen können trotzdem dazu führen, dass Seiten Datensätze wiederholen oder überspringen.

SQL-Klauseln haben eine feste Reihenfolge beim Schreiben. Ihre logische Reihenfolge erklärt das Ergebnis als eine Folge von Entscheidungen, selbst wenn die Datenbank einen anderen internen Ausführungsplan verwendet.

Die Anweisung in Klauselreihenfolge schreiben

SELECT DISTINCT city
FROM employees
WHERE department = 'Sales'
ORDER BY city
LIMIT 2 OFFSET 0;

SELECT und FROM bezeichnen die angeforderten Spalten und die Quelltabelle. Die anderen Klauseln sind optional, behalten aber, falls vorhanden, diese Reihenfolge bei: WHERE, ORDER BY, LIMIT und dann OFFSET in dieser LIMIT-Form. DISTINCT steht direkt nach SELECT.

Verwende eine WHERE-Klausel mit mehreren verknüpften Bedingungen. Ein zweites WHERE ist ein Syntaxfehler. Dasselbe gilt für ORDER BY: Setze mehrere Sortierspalten in eine Klausel und trenne sie durch Kommas. WHERE unter ORDER BY zu verschieben, verlangt keine andere Verarbeitungsreihenfolge, sondern erzeugt ungültiges SQL.

Die logischen Entscheidungen verfolgen

Das Ergebnis ist Chicago, dann Denver. Die wiederholte Stadt verschwindet, bevor die Begrenzung Ergebniszeilen zählt. Es werden nicht zwei Beschäftigte genommen und dann gefragt, ob sie in unterschiedlichen Städten wohnen.

Der Optimierer kann einen anderen physischen Ausführungsplan verwenden, der dasselbe Ergebnis wie diese logische Folge erzeugt.

Spalten dort verwenden, wo sie verfügbar sind

WHERE prüft die Quellzeilen, bevor SELECT die angezeigten Spalten auswählt:

SELECT first_name
FROM employees
WHERE salary > 60000;

Das funktioniert, ohne dass das Gehalt in der Ausgabe steht. Die passenden Namen sind Ben, Emma und Farid. Bei der Prüfung ist das Gehalt weiterhin eine Spalte jeder Quellzeile.

Ebenso ist das Filtern vor dem Begrenzen für ein Spitzenergebnis innerhalb einer Gruppe entscheidend:

SELECT first_name
FROM employees
WHERE department = 'Sales'
ORDER BY salary DESC
LIMIT 1;

Die Antwort ist Emma. Zuerst werden die Beschäftigten aus Sales ausgewählt; dann werden ihre Gehälter in eine Rangfolge gebracht. Würde man zuerst die Person mit dem höchsten Gehalt im Unternehmen nehmen und diese einzelne Zeile auf Sales prüfen, verfehlte man die beabsichtigte Antwort, weil Farid zu IT gehört.

Die Struktur sichtbar machen

Schreibe eine Klausel pro Zeile und setze längere Bedingungen auf separate eingerückte Zeilen. Für „Produkte aus Furniture unter 200 Dollar, höchster Preis zuerst“ verwende:

SELECT name, price
FROM products
WHERE category = 'Furniture'
  AND price < 200
ORDER BY price DESC;

Office Chair mit 149,00 kommt vor Bookshelf mit 120,00. Die beiden Bedingungen stehen in einem gemeinsamen WHERE, der numerische Schwellenwert hat kein Währungszeichen und ORDER BY sortiert die passenden Zeilen. Wenn du jede Zeile anhand ihrer Aufgabe prüfst, lassen sich sowohl Syntaxfehler als auch falsche Interpretationen leichter finden.

Bevor du SQL schreibst, bestimme die einzelnen Entscheidungen, die in einer alltäglichen Anfrage stecken. Jede Entscheidung gehört zu einer Klausel, und jede Klausel lässt sich anhand der beabsichtigten Antwort prüfen.

Sechs Entscheidungen treffen

1. Welche Tabelle enthält die Datensätze? Wähle FROM.
2. Welche Datensätze passen? Erstelle WHERE.
3. Welche Felder beantworten die Frage? Wähle SELECT.
4. Sind wiederholte Ergebniswerte nützlich? Entscheide über DISTINCT.
5. Was soll zuerst kommen? Erstelle ORDER BY.
6. Gibt es eine Obergrenze oder eine Seite? Ergänze LIMIT und OFFSET.

Bei „mindestens“ schließe Gleichheit ein. „Einer von“ deutet auf IN hin, „enthält“ auf ein LIKE-Muster mit Prozentzeichen an beiden Enden, „fehlend“ auf IS NULL und „unterschiedliche Werte“ auf DISTINCT. Eine Anfrage nach den ersten n Zeilen braucht sowohl eine Sortierrichtung als auch eine Begrenzung.

Eine Personalauswahl erstellen

„Zeige die Namen und Einstellungsdaten der drei zuletzt eingestellten Beschäftigten außerhalb von Sales, für die eine Telefonnummer hinterlegt ist, mit den neuesten zuerst.“ Schließe Beschäftigte ohne zugewiesene Abteilung in die Bedeutung von außerhalb von Sales in dieser Anfrage ein.

Beginne mit employees. Die passende Abteilungsregel lautet department <> 'Sales' OR department IS NULL. Gruppiere diese Auswahl, damit die Telefonregel für beide Zweige gilt. Zeige Namen und Daten an und bringe dann die passenden Zeilen in eine Rangfolge:

SELECT first_name, last_name, hire_date
FROM employees
WHERE (department <> 'Sales' OR department IS NULL)
  AND phone IS NOT NULL
ORDER BY hire_date DESC
LIMIT 3;

Grace Okafor vom 2024-02-19 steht zuerst, David Kim vom 2020-11-23 an zweiter und Farid Haddad vom 2017-09-12 an dritter Stelle. Entfernst du den IS-NULL-Zweig, fällt Grace heraus und nur zwei Ergebnisse bleiben. Kläre bei einer unklaren Anfrage, wie fehlende Abteilungen zählen sollen, und nenne die Entscheidung bei der Antwort.

Kategorie, Preis und Lagerbestand kombinieren

„Welche Produkte aus Lighting oder Storage kosten weniger als 20 Dollar und sind vorrätig, die günstigsten zuerst?“ Verwende IN für die beiden Kategorieoptionen und verlange eine bekannte positive Stückzahl:

SELECT name, price
FROM products
WHERE category IN ('Lighting', 'Storage')
  AND price < 20
  AND stock > 0
ORDER BY price;

Paper Tray mit 9,99 kommt vor Desk Organizer mit 18,75. Lamp Shade ist günstig genug und gehört zu einer ausgewählten Kategorie, sein Lagerbestand ist aber null, sodass es die letzte Prüfung nicht besteht. Auch eine fehlende Lagerstückzahl würde die Prüfung nicht bestehen, weil sie nicht belegen kann, dass der Lagerbestand positiv ist.

Die Zeilen prüfen, die einen Fehler aufdecken könnten

Beginne mit SELECT * FROM products LIMIT 5;, wenn du das Schema und einige Datensätze erkundest. Füge Filter einzeln hinzu, prüfe Änderungen der Ergebnisanzahl und zeige geprüfte Spalten vorübergehend an, wenn es hilfreich ist.

Prüfe genaue Grenzen, fehlende Werte, die Groß- und Kleinschreibung von Text und gleiche Werte an der Grenze. NOT zeigt Zeilen, bei denen eine Bedingung falsch war; es zeigt keine Zeilen, bei denen die Bedingung unbekannt war. Führe IS-NULL-Prüfungen gesondert aus. Prüfe, ob deine Ausgabe die angeforderten Spalten enthält und ob ORDER BY gleiche Werte auflöst, die die Antwort beeinflussen.

Prüfe beim Übertragen der Abfrage in eine andere Datenbank die Syntax für Zeilenbegrenzungen, die Regeln zur Groß- und Kleinschreibung bei Gleichheit und LIKE, Anführungszeichen für Bezeichner, die Behandlung von Datumswerten und die Platzierung von NULL. Die Beispiele verwenden LIMIT in SQLite und PostgreSQL; die Form für Zeilenbegrenzungen in Standard-SQL ist OFFSET mit FETCH FIRST.