UNNEST in SQL

UNNEST in SQL ist eines dieser Features, das dir sofort Zeit spart, wenn du mit Arrays oder verschachtelten Daten arbeitest. Statt komplizierte Workarounds zu bauen, zerlege ich damit Daten direkt in einzelne Zeilen. Das macht Abfragen einfacher, Analysen sauberer und Reports deutlich flexibler.

Was macht UNNEST in SQL?

UNNEST nimmt ein Array oder eine verschachtelte Struktur und macht daraus mehrere Zeilen. Genau das ist der Punkt. Ich habe also nicht mehr eine Zeile mit vielen Werten in einem Feld, sondern pro Wert eine eigene Zeile.

Ein einfaches Beispiel:

SELECT UNNEST(ARRAY[1, 2, 3]);

Das Ergebnis sind drei Zeilen mit den Werten 1, 2 und 3. Kein Zauber. Nur sauberer Datenzugriff.

Wann ich UNNEST in SQL nutze

Ich nutze UNNEST in SQL, wenn Daten nicht normalisiert sind oder wenn ein Feld mehrere Werte enthält. Typische Fälle:

• Tags, Kategorien oder Labels in einem Array
• Produktlisten in Bestellungen
• Events mit mehreren Attributen
• JSON-Strukturen mit verschachtelten Arrays
• Analytics-Daten in BigQuery, PostgreSQL oder Snowflake

Wenn ich das nicht auflöse, wird jede Analyse unnötig schwer. Mit UNNEST mache ich die Daten direkt auswertbar.

UNNEST in SQL: Grundsyntax

Die Syntax hängt leicht vom Datenbanksystem ab. Das Prinzip bleibt gleich. Ich zeige dir die gängigen Varianten.

PostgreSQL

SELECT *
FROM UNNEST(ARRAY['A', 'B', 'C']) AS t(value);

Mehr dazu findest du in der offiziellen PostgreSQL-Dokumentation: PostgreSQL Array Functions.

BigQuery

SELECT value
FROM UNNEST(['A', 'B', 'C']) AS value;

BigQuery beschreibt das hier: BigQuery Arrays.

Snowflake

SELECT value
FROM TABLE(FLATTEN(input => ARRAY_CONSTRUCT('A', 'B', 'C')));

Snowflake nutzt oft FLATTEN statt klassischem UNNEST. Die Doku dazu: Snowflake FLATTEN.

UNNEST in SQL mit mehreren Spalten

Oft reicht ein Array mit einem Wert nicht. Ich will den Wert zusammen mit einer ID, einem Datum oder einer Kategorie behalten. Dann kombiniere ich UNNEST mit einer bestehenden Tabelle.

SELECT
  user_id,
  tag
FROM users,
UNNEST(tags) AS tag;

Das ist stark, weil ich jede Zeile sauber aufsplitte und trotzdem den Kontext behalte.

Worauf ich bei UNNEST in SQL achte

UNNEST ist einfach. Aber einfach heißt nicht automatisch sauber. Hier sind die Dinge, die ich immer prüfe:

• Reihenfolge: Manche Systeme behalten die Reihenfolge nicht automatisch. Wenn sie wichtig ist, speichere ich sie explizit mit einem Index.
• Leere Arrays: Ein leeres Array kann zu null Ergebnissen führen. Das muss ich im Query-Design einkalkulieren.
• NULL-Werte: NULL ist nicht dasselbe wie ein leeres Array. Das macht einen echten Unterschied in der Analyse.
• Duplikate: UNNEST entfernt keine Duplikate. Wenn Werte mehrfach vorkommen, bleiben sie mehrfach drin.
• Performance: Bei sehr großen Arrays kann die Zeilenzahl explodieren. Dann filtere ich früh und gezielt.

UNNEST in SQL mit JOIN kombinieren

Ein häufiger Anwendungsfall ist der Join mit einer anderen Tabelle. Genau hier wird UNNEST richtig nützlich.

SELECT
  o.order_id,
  item
FROM orders o
CROSS JOIN UNNEST(o.items) AS item;

Ich verwende CROSS JOIN, wenn ich jedes Element aus dem Array mit der Ursprungzeile verknüpfen will. Das ist oft der schnellste Weg, um Bestelldaten, Eventdaten oder User-Events sauber aufzubrechen.

UNNEST in SQL für JSON-Daten

Viele moderne Daten liegen nicht mehr sauber normalisiert in Tabellen. Sie kommen als JSON rein. Dann ist UNNEST oft der erste Schritt, um aus Chaos wieder Struktur zu machen.

Wenn in einem JSON-Feld ein Array steckt, hole ich es raus, flache es ab und arbeite weiter mit normalen SQL-Operationen. Das ist viel besser, als alles im Anwendungscode zu lösen.

Die besten Tipps für saubere UNNEST-Queries

• Filter so früh wie möglich, bevor du große Arrays auflöst.
• Gib Spalten klare Aliase, damit deine Query lesbar bleibt.
• Prüfe NULL und leere Arrays getrennt.
• Nutze Aggregationen nach dem UNNEST, wenn du wieder auf eine höhere Ebene zurück willst.
• Dokumentiere die Datenstruktur, damit niemand später raten muss, was im Array steckt.

Häufige Fehler bei UNNEST in SQL

Ich sehe immer wieder dieselben Fehler:

• UNNEST wird ohne Alias verwendet, und die Query wird unlesbar.
• Mehrere Arrays werden falsch kombiniert und erzeugen falsche Zeilenmengen.
• NULL wird mit leerem Array verwechselt.
• Es wird unnötig früh unnested, obwohl erst später ein Filter greift.
• Die Abfrage wird nicht getestet, obwohl ein einzelnes Array komplett andere Ergebnisse erzeugen kann.

Mein Ansatz ist simpel: erst verstehen, dann auflösen, dann filtern, dann auswerten.

Wann UNNEST in SQL die falsche Lösung ist

UNNEST ist stark, aber nicht immer die beste Wahl. Wenn ich die Daten dauerhaft analysiere, ist eine saubere Normalisierung oft besser. Wenn Arrays nur aus schlechtem Datenmodell entstehen, sollte ich die Quelle lieber reparieren statt alles permanent zu zerlegen.

Ich nutze UNNEST also nicht als Krücke für schlechtes Design. Ich nutze es als Werkzeug für schnelle, klare Analysen.

Fazit zu UNNEST in SQL

UNNEST in SQL ist eines der nützlichsten Werkzeuge für Arrays, JSON und verschachtelte Daten. Es macht Daten auswertbar, Queries sauberer und Analysen schneller. Wenn ich weiß, wie ich es richtig einsetze, spare ich mir unnötige Komplexität und komme direkt zu brauchbaren Ergebnissen. Genau deshalb gehört UNNEST in SQL in jedes SQL-Playbook.