ANSI SQL Standard vs. Hersteller-Dialekte im Vergleich

1. Was der ANSI SQL Standard wirklich ist

Der Begriff ANSI SQL Standard wird in Diskussionen oft so verwendet, als gaebe es eine einzige, feste Spezifikation, die jede Datenbank entweder erfuellt oder verletzt. In Wirklichkeit ist der ANSI SQL Standard, gemeinsam mit seinem internationalen Gegenstueck ISO/IEC 9075, ein mehrteiliges Dokument, das in regelmaessigen Abstaenden erweitert wird und dabei zwischen verpflichtenden Kernfeatures (Core SQL) und optionalen Erweiterungspaketen unterscheidet. Kein einziges kommerzielles Datenbanksystem implementiert den gesamten Standard vollstaendig, und das ist auch nicht das Ziel der Spezifikation.

Die praktische Konsequenz: Wenn jemand sagt, eine Abfrage sei "Standard-SQL", meint er meist, dass sie Core-SQL-Features nutzt, die von den meisten grossen Systemen gleich interpretiert werden, nicht dass die Abfrage gegen die vollstaendige Spezifikation validiert wurde. Der ANSI SQL Standard definiert die Syntax fuer SELECT, JOIN, WHERE, Aggregatfunktionen und viele weitere Grundbausteine, laesst aber bewusst Spielraum fuer herstellerspezifische Erweiterungen, etwa bei Stored Procedures, bei prozeduralen Spracherweiterungen oder bei administrativen Befehlen, die naturgemaess systemspezifisch sind.

2. Von SQL-92 zu SQL:2016: die wichtigsten Revisionen

Die Entwicklung des ANSI SQL Standards zeigt, wie sich die Sprache ueber Jahrzehnte erweitert hat. SQL-92 war lange die Referenz, an der sich viele Datenbanksysteme orientierten, und definierte grundlegende Features wie Subqueries, OUTER JOIN Syntax und Integritaetsconstraints. SQL:1999 fuegte rekursive Abfragen ueber WITH RECURSIVE und objektrelationale Erweiterungen hinzu. SQL:2003 brachte Window Functions und die MERGE-Anweisung, die heute in fast jedem modernen System zu finden sind, wenn auch mit dialektspezifischen Unterschieden.

SQL:2016 fuegte native JSON-Unterstuetzung als Standard-Feature hinzu, ein Bereich, in dem die tatsaechlichen Implementierungen der Datenbanken lange vor der Standardisierung eigene Wege gegangen waren. Das ist ein wiederkehrendes Muster beim ANSI SQL Standard: Datenbankhersteller implementieren ein nuetzliches Feature zuerst proprietaer, weil der Markt es fordert, und der Standard folgt Jahre spaeter mit einer eigenen, oft leicht abweichenden Syntax. JSON-Operatoren sind das aktuellste Beispiel dafuer, dass Standardisierung der Praxis meist hinterherlaeuft statt sie anzufuehren.

-- SQL:1999 standard: recursive CTE for hierarchical data
WITH RECURSIVE org_chart AS (
    SELECT id, name, manager_id, 1 AS level
    FROM employees
    WHERE manager_id IS NULL

    UNION ALL

    SELECT e.id, e.name, e.manager_id, oc.level + 1
    FROM employees e
    JOIN org_chart oc ON e.manager_id = oc.id
)
SELECT * FROM org_chart ORDER BY level, name;

-- SQL:2003 standard: window function, supported with identical syntax
-- across PostgreSQL, MySQL 8+, Oracle, and SQL Server
SELECT
    department,
    employee_name,
    salary,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS salary_rank
FROM employees;

3. Standardisierte Datentypen und wo Hersteller abweichen

Der ANSI SQL Standard definiert eine Basismenge an Datentypen: CHARACTER, NUMERIC, INTEGER, DATE, TIME und TIMESTAMP gehoeren dazu. In der Praxis bieten alle grossen Systeme diese Typen unter aehnlichen Namen an, doch schon bei genauerem Hinsehen zeigen sich Unterschiede. VARCHAR ohne Laengenangabe ist in PostgreSQL gueltig, in vielen anderen Systemen aber ein Fehler. Der Standard-Typ NUMERIC hat in Oracle eine andere Default-Praezision als in PostgreSQL, und MySQL rundet bei bestimmten numerischen Operationen anders als vom Standard vorgesehen.

Noch deutlicher wird die Abweichung bei Typen, die der ANSI SQL Standard gar nicht kennt: Arrays, benutzerdefinierte Enum-Typen, geometrische Datentypen und natuerlich JSON-native Typen wie JSONB sind reine Hersteller-Erweiterungen. Wer Code schreibt, der auf mehreren Datenbanksystemen laufen soll, muss diese proprietaeren Typen entweder vermeiden oder durch eine Abstraktionsschicht kapseln, die je nach Zieldatenbank die passende Implementierung waehlt.

4. Standard-Syntax vs. proprietaere Kurzformen

Ein klassisches Beispiel fuer die Kluft zwischen dem ANSI SQL Standard und Hersteller-Dialekten ist die Pagination. Der Standard definiert seit SQL:2008 die Klausel FETCH FIRST n ROWS ONLY in Kombination mit OFFSET n ROWS, eine Syntax, die von Oracle, SQL Server (ab Version 2012) und PostgreSQL unterstuetzt wird. MySQL dagegen bevorzugt bis heute die eigene LIMIT-Klausel, die zwar kuerzer ist, aber keine Standard-Syntax darstellt. Wer portablen Code schreiben will, sollte FETCH FIRST nutzen, wo immer moeglich, auch wenn LIMIT in vielen Tutorials dominiert, weil es kuerzer zu tippen ist.

Aehnliches gilt fuer die String-Verkettung: Der ANSI SQL Standard definiert den Operator ||, den PostgreSQL, Oracle und SQL Server (in der Standard-Compatibility-Mode) unterstuetzen. MySQL nutzt stattdessen standardmaessig die Funktion CONCAT(). Da CONCAT() selbst kein Standard-Konstrukt im engeren Sinne ist, aber von praktisch allen Systemen unterstuetzt wird, hat sich CONCAT() in der Praxis als der pragmatischere, portablere Weg etabliert, selbst wenn er nicht der urspruenglichen ANSI SQL Standard Syntax entspricht.

-- SQL:2008 standard: FETCH FIRST, supported by PostgreSQL, Oracle, SQL Server
SELECT id, name, price
FROM products
ORDER BY price DESC
OFFSET 20 ROWS
FETCH FIRST 10 ROWS ONLY;

-- MySQL-specific (not standard, but widely used): LIMIT
SELECT id, name, price
FROM products
ORDER BY price DESC
LIMIT 10 OFFSET 20;

5. Window Functions: standardisiert, aber unterschiedlich implementiert

Window Functions sind seit SQL:2003 Teil des ANSI SQL Standards und gehoeren zu den am konsistentesten implementierten Features ueber alle grossen Datenbanksysteme hinweg. ROW_NUMBER(), RANK(), DENSE_RANK() und die OVER-Klausel mit PARTITION BY und ORDER BY funktionieren in PostgreSQL, MySQL ab Version 8, Oracle und SQL Server nahezu identisch. Das macht Window Functions zu einem guten Beispiel dafuer, dass Standardisierung funktionieren kann, wenn genug Marktdruck und Konsens vorhanden sind.

Doch auch hier gibt es Feinheiten: Das Verhalten von Window Frames (ROWS BETWEEN vs. RANGE BETWEEN) bei gleichen Werten in der Sortierspalte unterscheidet sich in Detailfaellen zwischen den Systemen, und nicht jede Datenbank unterstuetzt jede im Standard definierte Frame-Variante wie GROUPS. Wer Window Functions mit exotischeren Frame-Definitionen einsetzt, sollte die konkrete Implementierung der Zieldatenbank pruefen, statt sich blind auf den ANSI SQL Standard zu verlassen.

6. Common Table Expressions als Standard-Feature

Common Table Expressions (WITH-Klauseln) sind ein weiteres Beispiel fuer ein seit SQL:1999 standardisiertes Feature, das in modernen Versionen aller grossen Datenbanken vorhanden ist. Die grundlegende Syntax WITH cte_name AS (SELECT ...) ist ueberall identisch. Unterschiede zeigen sich bei fortgeschrittenen Optionen: PostgreSQL erlaubt MATERIALIZED und NOT MATERIALIZED als explizite Optimierungshinweise, waehrend andere Systeme diese Entscheidung dem Optimizer ueberlassen, ohne dass der Entwickler Einfluss nehmen kann.

Rekursive CTEs mit WITH RECURSIVE sind ebenfalls Standard, allerdings verlangt MySQL das Schluesselwort RECURSIVE explizit, waehrend SQL Server und aeltere Oracle-Versionen es ohne dieses Schluesselwort akzeptieren, aber mit derselben Semantik. Diese kleinen syntaktischen Unterschiede zeigen exemplarisch, dass selbst gut standardisierte Features nie zu hundert Prozent identisch implementiert werden, weil jeder Hersteller eigene historische Altlasten und Kompatibilitaetsentscheidungen mitbringt.

-- Standard CTE syntax, works identically almost everywhere
WITH high_value_orders AS (
    SELECT customer_id, SUM(total) AS total_spent
    FROM orders
    GROUP BY customer_id
    HAVING SUM(total) > 1000
)
SELECT c.name, hvo.total_spent
FROM customers c
JOIN high_value_orders hvo ON hvo.customer_id = c.id
ORDER BY hvo.total_spent DESC;

-- PostgreSQL-specific optimization hint (non-standard extension)
WITH high_value_orders AS MATERIALIZED (
    SELECT customer_id, SUM(total) AS total_spent
    FROM orders
    GROUP BY customer_id
)
SELECT * FROM high_value_orders WHERE total_spent > 1000;

7. Beliebte Features, die der Standard gar nicht kennt

Einige der am haeufigsten genutzten Datenbank-Features haben ueberhaupt keine Entsprechung im ANSI SQL Standard, weil sie zu eng an die interne Architektur eines konkreten Systems gebunden sind. Die Upsert Syntax gehoert dazu: ON CONFLICT in PostgreSQL und ON DUPLICATE KEY UPDATE in MySQL sind reine Dialekt-Erweiterungen, der Standard kennt stattdessen nur die deutlich umstaendlichere MERGE-Anweisung, die zwar seit SQL:2003 standardisiert ist, in der Praxis aber selten in der vollen Standard-Form genutzt wird.

Auch Replikations-Befehle, Backup-Syntax, Storage-Engine-Angaben und Indexierungs-Hinweise wie USE INDEX oder WITH (NOLOCK) sind reine Hersteller-Erweiterungen ohne jede Entsprechung im ANSI SQL Standard. Das ist auch folgerichtig: Der Standard beschreibt die logische Abfragesprache, nicht die physische Speicherarchitektur einer konkreten Datenbank. Wer diese Grenze verinnerlicht, versteht sofort, warum manche SQL-Konstrukte portabel sind und andere niemals sein werden, unabhaengig davon, wie viele zukuenftige Standard-Revisionen noch erscheinen.

8. Strategien fuer standardnahen, portablen Code

Wer Anwendungen entwickelt, die auf mehreren Datenbanksystemen laufen sollen, oder wer schlicht zukunftssicheren Code schreiben will, sollte sich am ANSI SQL Standard orientieren, wo immer es praktikabel ist. Das bedeutet konkret: FETCH FIRST statt LIMIT, CAST() statt proprietaerer Konvertierungsfunktionen, Standard-Datentypen statt herstellerspezifischer Erweiterungen, und der bewusste Verzicht auf Stored-Procedure-Sprachen wie PL/pgSQL oder T-SQL zugunsten von Anwendungslogik, wenn Portabilitaet Prioritaet hat.

Gleichzeitig ist vollstaendige Standard-Konformitaet selten das richtige Ziel. Wer bewusst nur auf PostgreSQL setzt, verschenkt Performance und Ausdruckskraft, wenn er auf JSONB, GIN-Indizes oder MATERIALIZED-CTEs verzichtet, nur um theoretisch portabel zu bleiben. Die pragmatische Regel lautet: Standard-SQL fuer den Kern der Anwendungslogik nutzen, dialektspezifische Features gezielt und dokumentiert dort einsetzen, wo sie einen echten Mehrwert bringen, und diese Stellen im Code klar markieren, damit ein spaeterer Wechsel der Datenbank gezielt moeglich bleibt.

9. Standard vs. Dialekt im direkten Vergleich

Die folgende Tabelle ordnet gaengige SQL-Features danach ein, ob sie Teil des ANSI SQL Standards sind oder eine reine Hersteller-Erweiterung darstellen.

Die Tabelle macht deutlich, dass der ANSI SQL Standard eher ein wachsender, gemeinsamer Kern ist als eine vollstaendige Spezifikation aller praktisch benoetigten Features. Neuere Funktionalitaet entsteht fast immer zuerst als Hersteller-Erweiterung und wird, wenn ueberhaupt, erst Jahre spaeter standardisiert, meist mit einer eigenen, leicht abweichenden Syntax gegenueber der urspruenglichen proprietaeren Implementierung.

10. Zusammenfassung

Der ANSI SQL Standard ist kein vollstaendiges Regelwerk, das jede Datenbank identisch macht, sondern ein wachsender gemeinsamer Kern, an den sich die grossen Systeme unterschiedlich stark annaehern. Window Functions und Common Table Expressions gehoeren zu den am konsistentesten umgesetzten Standard-Features, waehrend Upsert-Syntax, proprietaere Datentypen und administrative Befehle fast vollstaendig herstellerspezifisch bleiben. Wer diesen Unterschied kennt, trifft bewusstere Entscheidungen darueber, wo Portabilitaet realistisch ist und wo sie unnoetigen Verzicht auf leistungsfaehige Features bedeuten wuerde.

Der pragmatische Weg liegt selten in radikaler Standard-Treue und ebenso selten in blindem Vertrauen auf herstellerspezifische Syntax. Stattdessen lohnt sich eine bewusste, dokumentierte Entscheidung pro Feature: Ist eine Standard-Alternative verfuegbar und ausreichend performant, wird sie genutzt. Bringt eine Dialekt-Erweiterung einen klaren Vorteil, wird sie eingesetzt, aber an zentraler Stelle im Code sichtbar gemacht, damit ein spaeterer Wechsel der Datenbank nicht zur Ueberraschung wird.

11. FAQ: ANSI SQL Standard vs. Hersteller-Dialekte