PARTITION BY: praktische Beispiele fur Gruppen-Analysen

1. Was PARTITION BY macht und warum Zeilen erhalten bleiben

PARTITION BY wird dabei fast nie isoliert eingesetzt, sondern fast immer im Zusammenspiel mit mindestens einer Aggregat- oder Window-only-Funktion, deren Berechnungsgrundlage es definiert. Ohne eine solche Funktion in derselben SELECT-Klausel hat PARTITION BY keinen erkennbaren Effekt auf das Ergebnis, weshalb es syntaktisch immer innerhalb einer OVER-Klausel steht und niemals allein verwendet wird.

PARTITION BY ist der Bestandteil der OVER-Klausel, der die Ergebnismenge einer Abfrage in logische Untergruppen aufteilt, innerhalb derer eine Window Function unabhangig voneinander rechnet. Der entscheidende Unterschied zu GROUP BY: PARTITION BY fasst die Zeilen einer Gruppe niemals zu einer einzigen Ergebniszeile zusammen. Jede Zeile bleibt einzeln sichtbar, erhalt aber zusatzlich den Wert, der aus ihrer jeweiligen Partition berechnet wurde. Genau dieses Verhalten macht PARTITION BY zum Werkzeug fur Gruppen-Analysen, bei denen sowohl Detail als auch Kontext gebraucht werden.

Ein anschauliches Beispiel: Ein Unternehmen mochte fur jeden einzelnen Auftrag sehen, wie er sich zum Durchschnitt seiner Region verhalt. Mit GROUP BY erhielte man nur eine Zeile pro Region mit dem Durchschnittswert, die einzelnen Auftrage waren verloren. Mit PARTITION BY region bleibt jeder Auftrag als eigene Zeile erhalten, und der regionale Durchschnitt steht als zusatzliche Spalte daneben. Diese Eigenschaft von PARTITION BY ist der Grund, warum es in Reporting-Abfragen so haufig zum Einsatz kommt, wo Detailtabellen mit Kontextinformation angereichert werden mussen.

2. Syntax: PARTITION BY im Detail

Ein haufig gestellter Anfangerfehler ist der Versuch, PARTITION BY ausserhalb einer OVER-Klausel zu verwenden, etwa direkt nach FROM oder als Ersatz fur GROUP BY. PARTITION BY existiert ausschliesslich innerhalb der Klammern von OVER und hat ausserhalb dieses Kontexts keine Bedeutung in Standard-SQL, was diesen Fehler bei Einsteigern besonders haufig macht.

Die Syntax von PARTITION BY ist bewusst einfach gehalten: Innerhalb der Klammern von OVER folgt auf das Schlusselwort PARTITION BY eine kommagetrennte Liste von einer oder mehreren Spalten. PARTITION BY steht dabei immer vor einem eventuell vorhandenen ORDER BY innerhalb derselben OVER-Klausel. Fehlt PARTITION BY komplett, behandelt die Datenbank die gesamte Ergebnismenge als eine einzige Partition, was fur globale Berechnungen wie einen Gesamtdurchschnitt uber alle Zeilen sinnvoll ist.

Wichtig zu verstehen ist, dass PARTITION BY ausschliesslich die Berechnungsgrundlage der Window Function beeinflusst, nicht die Ausgabe der Abfrage selbst. Es filtert keine Zeilen heraus und sortiert die Ausgabe nicht. Fur die Sortierung der Ergebniszeilen bleibt weiterhin die abschliessende ORDER BY-Klausel der gesamten Abfrage zustandig, die unabhangig vom PARTITION BY innerhalb der OVER-Klausel existiert und eine vollig andere Aufgabe erfullt.

-- Basic PARTITION BY: regional average next to each order
SELECT
    order_id,
    region,
    order_amount,
    AVG(order_amount) OVER (PARTITION BY region) AS region_avg
FROM orders
ORDER BY region, order_amount DESC;

-- Result (excerpt)
-- order_id | region | order_amount | region_avg
-- 1042     | North  |         1250 |     980.50
-- 1055     | North  |          900 |     980.50
-- 1071     | South  |         1500 |    1120.00

Bei der Wahl einer sinnvollen Partitionierungsspalte lohnt sich vorab eine kurze Uberlegung zur Kardinalitat der Spalte, also der Anzahl unterschiedlicher Werte. Eine Spalte mit nur zwei oder drei unterschiedlichen Werten erzeugt sehr grosse Partitionen, in denen die Window Function uber viele tausend Zeilen rechnen muss. Eine Spalte mit sehr hoher Kardinalitat, etwa eine eindeutige ID, erzeugt dagegen Partitionen mit jeweils nur einer einzigen Zeile, was die Aggregation faktisch bedeutungslos macht. Die praktisch sinnvollste Partitionierungsspalte liegt meist irgendwo dazwischen, etwa eine Kategorie, eine Region oder ein Kalendermonat.

3. Ein-Spalten-Partitionierung: einfaches Beispiel

Die einfachste Form von PARTITION BY partitioniert nach genau einer Spalte, etwa nach Kundengruppe, Produktkategorie oder Abteilung. Diese Form ist der Standardfall in den meisten Reporting-Abfragen und reicht fur einen grossen Teil der praktischen Anwendungsfalle aus. Man kombiniert typischerweise PARTITION BY mit einer Aggregatfunktion wie SUM, AVG oder COUNT, um pro Gruppe eine Kennzahl zu berechnen, die dann jeder Zeile der Gruppe als Kontext zur Seite gestellt wird.

Ein haufiges Praxisbeispiel ist die Berechnung des Anteils eines einzelnen Datensatzes an der Gesamtsumme seiner Gruppe. Mit betrag / SUM(betrag) OVER (PARTITION BY kategorie) lasst sich pro Zeile der prozentuale Anteil am Kategorieumsatz berechnen, ohne eine zweite Abfrage oder einen Self-Join zu benotigen. Diese Art von Anteils-Berechnung gehort zu den haufigsten Grunden, PARTITION BY uberhaupt einzusetzen, weil sie mit klassischem GROUP BY praktisch nicht in einer einzigen Abfrage machbar ist.

-- Single-column partitioning: share of each product within its category
SELECT
    category,
    product_name,
    revenue,
    ROUND(
        100.0 * revenue / SUM(revenue) OVER (PARTITION BY category),
        2
    ) AS pct_of_category_revenue
FROM product_revenue
ORDER BY category, revenue DESC;

4. Mehr-Spalten-Partitionierung: mehrdimensionale Gruppen

Ein weiterer Grund fur den Einsatz mehrerer Partitionierungsspalten ist die Notwendigkeit, hierarchische Geschaftsstrukturen korrekt abzubilden. Ein Konzern mit mehreren Landesgesellschaften, die wiederum mehrere Filialen betreiben, benotigt fur eine filialgenaue Auswertung mit landesweitem Kontext eine Partitionierung nach Land und Filiale gleichzeitig. Ohne diese Mehr-Spalten-Partitionierung musste man entweder zwei separate Abfragen schreiben oder mit verschachtelten Subqueries arbeiten, was die Wartbarkeit des SQL-Codes erheblich verschlechtert.

PARTITION BY ist nicht auf eine einzelne Spalte beschrankt. Werden mehrere Spalten kommagetrennt angegeben, etwa PARTITION BY region, produktkategorie, entsteht eine mehrdimensionale Gruppierung: Zwei Zeilen gehoren nur dann zur selben Partition, wenn beide Spaltenwerte ubereinstimmen. Diese Technik ist notwendig, sobald eine Analyse nach mehr als einem Merkmal gleichzeitig gruppieren soll, etwa Umsatz pro Region und Kalenderjahr, um Jahresvergleiche innerhalb jeder Region zu ermoglichen.

Die Reihenfolge der Spalten in PARTITION BY hat auf das Ergebnis der Window Function selbst keinen Einfluss, im Gegensatz zur Reihenfolge in einer GROUP BY-Klausel mit ROLLUP oder CUBE, bei denen die Spaltenreihenfolge Zwischensummen beeinflusst. Bei PARTITION BY bestimmt allein die Kombination der Spaltenwerte, welche Zeilen zur selben Gruppe gehoren, unabhangig davon, ob region vor oder nach produktkategorie steht. Diese Eigenschaft macht Mehr-Spalten-Partitionierung vorhersehbar und leicht erweiterbar, wenn eine weitere Dimension hinzukommt.

-- Multi-column PARTITION BY: revenue share within region AND category
SELECT
    region,
    product_category,
    product_name,
    revenue,
    SUM(revenue) OVER (
        PARTITION BY region, product_category
    ) AS category_total_in_region,
    ROUND(
        100.0 * revenue / SUM(revenue) OVER (PARTITION BY region, product_category),
        2
    ) AS pct_of_category
FROM product_revenue
ORDER BY region, product_category, revenue DESC;

5. PARTITION BY kombiniert mit ORDER BY

Diese Kombination erlaubt es ausserdem, innerhalb einer Partition mehrere unterschiedliche Sortierkriterien fur verschiedene Window Functions in derselben Abfrage zu verwenden. Eine Abfrage kann gleichzeitig ROW_NUMBER() OVER (PARTITION BY kategorie ORDER BY umsatz DESC) fur ein Ranking nach Umsatz und LAG(preis) OVER (PARTITION BY kategorie ORDER BY datum) fur einen zeitlichen Preisvergleich enthalten, wobei beide Funktionen dieselbe Partition, aber unterschiedliche Sortierlogik nutzen. Diese Unabhangigkeit von PARTITION BY und ORDER BY je Window Function macht komplexe, mehrdimensionale Auswertungen in einer einzigen Abfrage moglich.

Die eigentliche Starke von PARTITION BY zeigt sich erst in Kombination mit ORDER BY innerhalb derselben OVER-Klausel. PARTITION BY definiert die Gruppe, ORDER BY die Reihenfolge der Zeilen innerhalb dieser Gruppe. Diese Kombination ist die Grundlage fur alle positionsabhangigen Berechnungen pro Gruppe: laufende Summen pro Kunde, Rangfolgen pro Kategorie, oder der Zugriff auf die vorherige Zeile innerhalb derselben Region mit LAG.

Wichtig ist die Reihenfolge der Klauseln: PARTITION BY steht immer vor ORDER BY innerhalb der Klammern. PARTITION BY region ORDER BY order_date bedeutet: bilde zunachst Gruppen nach Region, sortiere dann innerhalb jeder Region die Zeilen nach Datum. Die Window Function arbeitet danach ausschliesslich innerhalb dieser sortierten Gruppen, ohne dass Zeilen aus einer anderen Region jemals in die Berechnung einer Region einfliessen.

6. Laufende Berechnungen pro Gruppe ohne Kollabieren

Diese Eigenschaft ist besonders wertvoll bei Datenmigrationen und Konsolidierungsprojekten, bei denen historische Daten aus mehreren Quellsystemen zusammengefuhrt werden. Eine laufende Prufsumme pro Quellsystem, berechnet mit PARTITION BY quellsystem, deckt Unstimmigkeiten sofort auf, ohne dass fur jedes Quellsystem eine eigene Abfrage geschrieben werden muss.

Eine der praktisch wertvollsten Anwendungen von PARTITION BY ist die laufende Berechnung innerhalb einer Gruppe, ohne dass die Detailzeilen dabei kollabieren. Ein klassisches Beispiel ist eine laufende Summe pro Kunde: SUM(betrag) OVER (PARTITION BY kunde_id ORDER BY bestelldatum) liefert fur jede Bestellung eines Kunden die Summe aller bisherigen Bestellungen dieses Kunden, beginnend bei null und wachsend mit jeder weiteren Zeile. Sobald ein neuer Kunde beginnt, startet die laufende Summe automatisch wieder bei null, weil PARTITION BY die Gruppen sauber voneinander trennt.

Ohne PARTITION BY wurde dieselbe Berechnung eine globale laufende Summe uber alle Kunden hinweg erzeugen, was fachlich in den meisten Fallen keinen Sinn ergibt. Das Zuruckset­zen pro Gruppe ist keine zusatzliche Logik, die man explizit programmieren muss, sondern eine automatische Folge davon, dass PARTITION BY jede Gruppe als eigenstandige Berechnungseinheit behandelt. Dieses Verhalten spart in der Praxis erhebliche Mengen an Subquery- und Self-Join-Code gegenuber alteren SQL-Ansatzen.

Ein weiteres praktisches Beispiel fur laufende Berechnungen pro Gruppe ist die Ermittlung der Position einer Zeile innerhalb ihrer Partition, kombiniert mit dem Gruppenmaximum. Mit MAX(betrag) OVER (PARTITION BY kategorie) lasst sich pro Zeile direkt ablesen, wie weit der eigene Wert vom besten Wert der Kategorie entfernt ist, ohne eine zweite Abfrage zu benotigen. Diese Art von Vergleich zum Gruppenmaximum oder Gruppenminimum ist in Qualitatskontrollen, Preisvergleichen und Leistungsbewertungen ein wiederkehrendes Muster, das PARTITION BY in einer einzigen, gut lesbaren Abfrage lost.

-- Running total per customer, resetting cleanly at each new partition
SELECT
    customer_id,
    order_date,
    order_amount,
    SUM(order_amount) OVER (
        PARTITION BY customer_id
        ORDER BY order_date
    ) AS running_total_per_customer
FROM orders
ORDER BY customer_id, order_date;

7. PARTITION BY mit verschiedenen Aggregatfunktionen

Diese Vielseitigkeit macht PARTITION BY zu einer der am haufigsten verwendeten Klauseln in produktiven Analytics-Abfragen, weit uber die reinen Summen- und Durchschnittsberechnungen hinaus.

PARTITION BY lasst sich mit praktisch jeder Aggregatfunktion kombinieren, nicht nur mit SUM und AVG. COUNT(*) OVER (PARTITION BY status) liefert die Anzahl der Zeilen je Statuswert, nutzlich fur Auslastungsanalysen. MIN und MAX innerhalb einer Partition identifizieren den fruhesten oder spatesten Wert pro Gruppe, etwa das erste Bestelldatum eines Kunden, das dann jeder seiner Bestellzeilen als Referenzwert zur Seite gestellt werden kann.

Auch die Window-only-Funktionen wie ROW_NUMBER, RANK und LAG profitieren enorm von PARTITION BY, weil sie ihre Positionslogik dann pro Gruppe statt global anwenden. ROW_NUMBER() OVER (PARTITION BY kunde_id ORDER BY bestelldatum) nummeriert die Bestellungen jedes Kunden separat durch, beginnend bei 1 fur jeden neuen Kunden. Diese Kombination aus PARTITION BY und einer Window-only-Funktion ist eines der am haufigsten wiederkehrenden Muster in produktiven SQL-Abfragen fur Reporting und Analytics.

8. Haufige Fehler bei PARTITION BY

Auch die Kombination mit LAG und LEAD profitiert stark von einer bewusst gewahlten Partitionierung, da beide Funktionen ohne PARTITION BY zeilenweise uber die gesamte, unpartitionierte Ergebnismenge hinweg lesen wurden, was bei mehreren Gruppen in derselben Abfrage zu inhaltlich falschen Vergleichen zwischen unterschiedlichen Gruppen fuhren kann.

Der haufigste Fehler beim Einsatz von PARTITION BY ist die Verwechslung mit einem WHERE-Filter. PARTITION BY schrankt weder die Ergebniszeilen noch die Eingabezeilen ein, es andert nur, uber welche Zeilen die Window Function rechnet. Wer glaubt, PARTITION BY region = 'Nord' wurde die Ausgabe auf die Region Nord beschranken, verwendet die Klausel grundlegend falsch, denn PARTITION BY erwartet nur eine Spaltenliste, keine Filterbedingung. Eine echte Einschrankung der Ergebnismenge erfolgt weiterhin ausschliesslich uber WHERE vor der Window Function.

Ein zweiter haufiger Fehler ist das Fehlen von ORDER BY, wenn die Window Function eigentlich eine positionsabhangige Berechnung durchfuhren soll. PARTITION BY allein liefert nur einen konstanten Wert pro Gruppe, etwa den Gruppendurchschnitt. Wird zusatzlich eine laufende Summe oder ein Rang benotigt, muss ORDER BY zwingend mit angegeben werden, sonst liefert die Datenbank entweder einen Fehler oder ein Ergebnis, das nicht der fachlichen Erwartung entspricht, weil ohne ORDER BY keine wohldefinierte Reihenfolge innerhalb der Partition existiert.

Ein dritter praktischer Fehler entsteht, wenn Entwickler PARTITION BY und die abschliessende ORDER BY-Klausel der Abfrage verwechseln und annehmen, PARTITION BY wurde die Reihenfolge der Ausgabezeilen bestimmen. Beide Klauseln haben nichts miteinander zu tun: PARTITION BY beeinflusst ausschliesslich, welche Zeilen fur die Window-Function-Berechnung zusammengehoren, wahrend die Sortierung der Ausgabe unabhangig davon uber ein eigenes, abschliessendes ORDER BY am Ende der Abfrage gesteuert wird. Wer eine sortierte Ausgabe erwartet, muss dieses abschliessende ORDER BY explizit angeben, selbst wenn PARTITION BY und ORDER BY innerhalb der OVER-Klausel dieselben Spalten referenzieren.

-- Common mistake: PARTITION BY is not a filter
-- WRONG: this is a syntax error, PARTITION BY only takes a column list
-- SELECT * FROM orders OVER (PARTITION BY region = 'North')

-- RIGHT: filter with WHERE, then partition for the calculation
SELECT
    order_id,
    region,
    order_amount,
    AVG(order_amount) OVER (PARTITION BY region) AS region_avg
FROM orders
WHERE region = 'North';

9. Performance-Uberlegungen bei grossen Partitionen

In Datenbanksystemen mit Unterstutzung fur partitionierte Tabellen auf Speicherebene, zu unterscheiden von der logischen PARTITION BY-Klausel in der Abfrage, kann eine physische Tabellenpartitionierung, die mit den haufig verwendeten PARTITION-BY-Spalten ubereinstimmt, zusatzlich zur logischen Partitionierung Performance-Vorteile bringen, weil die Datenbank ganze Speicherpartitionen ausschliessen kann, bevor die eigentliche Window-Function-Berechnung beginnt.

Bei sehr grossen Tabellen mit vielen unterschiedlichen Partitionswerten lohnt sich ein zusammengesetzter Index, der die PARTITION-BY-Spalten an erster Stelle und die ORDER-BY-Spalten an zweiter Stelle enthalt. Ein solcher Index erlaubt es dem Optimizer, die Daten bereits sortiert nach Partition zu lesen, statt einen separaten und potenziell teuren Sortierschritt fur die gesamte Ergebnismenge durchzufuhren. Gerade bei Tabellen mit Millionen von Zeilen und vielen kleinen Partitionen kann dieser Unterschied erheblich sein.

Ein weiterer Aspekt: Sehr grosse einzelne Partitionen, etwa wenn PARTITION BY nach einer Spalte mit wenigen unterschiedlichen Werten gruppiert, konzentrieren die gesamte Berechnungslast auf wenige, dafur riesige Gruppen. In solchen Fallen kann eine feinere, mehrspaltige Partitionierung die Arbeit gleichmassiger verteilen und dadurch die Parallelisierbarkeit der Abfrage im Ausfuhrungsplan verbessern, sofern das Datenbanksystem parallele Ausfuhrung fur Window Functions unterstutzt.

Abschliessend sei erwahnt, dass sich PARTITION BY auch hervorragend mit CASE-Ausdrucken kombinieren lasst, um dynamische, datenabhangige Gruppen zu bilden, die nicht direkt einer vorhandenen Spalte entsprechen. PARTITION BY CASE WHEN betrag > 1000 THEN 'gross' ELSE 'klein' END erzeugt beispielsweise zwei Gruppen basierend auf einem Schwellenwert, ohne dass diese Kategorisierung vorher als eigene Spalte in der Tabelle existieren muss. Diese Technik erweitert die Einsatzmoglichkeiten von PARTITION BY erheblich, insbesondere in explorativen Analysen, bei denen Gruppierungskriterien haufig angepasst werden.

10. Zusammenfassung

Zusammengefasst ist PARTITION BY damit weniger ein eigenstandiges Werkzeug als vielmehr der Baustein, der aus einer globalen Window-Function-Berechnung eine gruppierte macht, ohne die grundlegenden Vorteile von Window Functions, namlich der Erhalt aller Detailzeilen, aufzugeben.

PARTITION BY teilt eine Ergebnismenge in logische Gruppen auf, ohne dabei jemals eine einzige Zeile zu verlieren. Der Unterschied zu GROUP BY ist fundamental: Statt einer Ergebniszeile pro Gruppe bleibt jede Detailzeile erhalten und erhalt zusatzlich einen aus ihrer Partition berechneten Wert. Ein-Spalten-Partitionierung deckt den grossten Teil der praktischen Falle ab, Mehr-Spalten-Partitionierung ermoglicht mehrdimensionale Gruppierungen, und die Kombination mit ORDER BY macht positionsabhangige Berechnungen wie laufende Summen und Rangfolgen pro Gruppe erst moglich.

In der Praxis ersetzt PARTITION BY zahlreiche Subqueries und Self-Joins, die sonst notig waren, um Detail- und Aggregatdaten in derselben Abfrage zu vereinen. Wer die haufigsten Fehler kennt, die Verwechslung mit einem Filter und das Vergessen von ORDER BY bei positionsabhangigen Berechnungen, kann PARTITION BY sicher und produktiv fur Gruppen-Analysen jeder Grossenordnung einsetzen.

11. FAQ: PARTITION BY fur Gruppen-Analysen