Wieso soll es bei verkauften Produkten Ärger geben ? Genau darum geht es bei mir. Die Parameter betreffen auch hauptsächlich die Where-Klausel. Die Datenmenge soll ja von Anfang an gering gehalten werden.
Und die 150 Zeilen kommen in meinem Beispiel nur zustande, weil es eben um 12 Monate geht. Ergibt halt solche Konstrukte (hier 1 Monat und das mal 12 + Where + Var.-Deklarationen) :
Code:
SUM (CASE MONAT WHEN 1 Then
CASE :WERTTYP
WHEN 0 THEN MENGE
WHEN 1 THEN UMSATZ
...geht bis 4
ELSE
0
END
ELSE 0 END) as Mon1,
Ja, das seh ich auch so, Deine 12 Monate sind 12 feste Spalten. Die Datenreduktion erfolgt auch, ob bei der Aggregation jetzt 10 oder 150 Sätze rauskommen, ist ja wurscht, Hauptsache es kommt nicht die unaggregierte Menge zurück.
Ich saug mir mal ein Beispiel aus den Fingern: Der Kunde möchte eine Pivotmatrix des Umsatzes über alle Produktkategorien, die eine bestimmte Umsatzgrenze übersteigen je Filiale. Die Produktkategorien kann er natürlich selber vergeben. Das Ergebnis ist hier in beiden Dimensionen variabel, Anzahl und Name (sagen wir Standort) der Filialen ist beliebig und Anzahl der Kategorien und deren Name auch. Das kann eine
SQL Engine nicht direkt, selbst wenn sie eine Pivotimplementierung hat. Also gut, ich kenne zumindest keine.
Und so wird es unkomfortabel und Du landest bei dynamischen
SQL, SP oder nicht, wie auch immer.