Seite 2 von 2

Re: Datum

Verfasst: Mo 19. Aug 2019, 14:21
von castorp
Wenn es irgendwie geht, sollte man pivot/crosstab grundsätzlich in der Anwendung machen, die die Daten anzeigt. Das ist wesentlich leichter und flexibler (und macht auch das SQL deutlich einfacher).

Wenn es wirklich mal sein muss, dass man mehrere Zeilen zu Spalten transponieren muss, gehe ich eigentlich mehr und mehr dazu über, die dynamischen "Spalten" in eine JSON Spalte zu aggregieren. In den meisten Fällen ist das fast genauso gut, und deutlich einfacher zu verwenden - und es ist vollständig "dynamisch". Wenn neue Werte für die "Spalten" hinzukommen passiert das automatisch, ohne dass man das Statement ändern müsste.

Z.b. so wie hier beschrieben: https://blog.sql-workbench.eu/post/pivot-alternatives/

Re: Datum

Verfasst: Mo 19. Aug 2019, 14:57
von simar
hört sich gut an, aaaaber mir zu schwierig

Re: Datum

Verfasst: Mo 19. Aug 2019, 15:00
von castorp
Dann mach's in der Anwendung wenn Du die Daten anzeigst.

Re: Datum

Verfasst: Mo 19. Aug 2019, 15:17
von simar
wie meinst du das?

das ist meine Anzeige aus Abfrage
nr | erg | wie oft
-----+-----
100 | 10 | 3
100 | 9 | 1
100 | 8 | 1
200 | 10 | 1
200 | 1 | 1
200 | 7 | 2

Re: Datum

Verfasst: Di 20. Aug 2019, 08:15
von Gisman
Du meinst ein Pivot? Mit crosstab sollte das gehen, ist aber IMHO recht umständlich. Wie wird das am Ende denn dargestellt? Ich mache solche Darstellungen meist im jeweiligen Client.
Gruß Uwe

Re: Datum

Verfasst: Di 20. Aug 2019, 22:05
von pogomips
crosstab wurde ja eigentlich schon genannt (sogar vom TE).
Es ist halt wie ebenfalls genannt nicht dynamisch, was problematisch ist.
Wenn, dann könnte im Fall hier nur die Variante mit 2 Selects, eins für Daten, eins für Header genommen werden.
Ein Select für Header ergibt aber dynamische Ergebnisse, außer man sorgt absichtlich dafür, dass das Headerstatement ein statisches Ergebnis hat. Hier vielleicht mit generate series 1-10 oder sowas.