Ingres: Zeilen als Spalten

[Fehler]

Moin zusammen,

ich habe in Ingres mal wieder eine kleine Herausforderung...
Ein Patient hat 2x eine Untersuchung bekommen wozu es jeweils 2 Ergebnisse gibt, also 4 Zeilen in der DB.

Beispiel-Tabelle
Patientennummer | Untersuchungsnummer | Untersuchungsbezeichnung | Untersuchungsergebnis
8 | 1 | "puls" | 70
8 | 1 | "Sp02" | 99
8 | 2 | "puls" | 76
8 | 2 | "Sp02" | 98

Als Ergebnis hätte ich gerne 2 Zeilen wie folgt:
8 | 1 | "puls" | 70 | "Sp02" | 99
8 | 2 | "puls" | 76 | "Sp02" | 98

Vermutlich muss ich mit GROUP BY arbeiten, habe nur keine Ahnung wie...

 

[dabadepdu]

Jein, Du brauchst etwas wie PIVOT. Ich weiß nicht, ob Ingres das kann.
Es gibt für PIVOT workarounds mit CASE WHEN.

Was auch in Frage kommt, ist die Umsetzung der Transformation im Report Tool, jenachdem, was man dort einsetzt.
Ich hoffe mal, Du brauchst das nur für die Ausgabe / Anzeige, alles andere wäre fragwürdig.

 

[akretschmer]

Warum die dritte und fünfte Spalte, die ist doch dann immer gleich. Vielleicht besser so?

test=# select * from fehler ;
 pnummer | unummer | bez  | erg 
---------+---------+------+-----
       8 |       1 | puls |  70
       8 |       1 | spo2 |  99
       8 |       2 | puls |  76
       8 |       2 | spo2 |  98
(4 rows)

test=# select pnummer, unummer, sum(case when bez = 'puls' then erg else 0 end) as puls, sum(case when bez = 'spo2' then erg else 0 end) as spo2 from fehler group by pnummer, unummer order by pnummer, unummer;
 pnummer | unummer | puls | spo2 
---------+---------+------+------
       8 |       1 |   70 |   99
       8 |       2 |   76 |   98
(2 rows)

test=#

 

[Fehler]

Tunnelblick!
Ich meinte das eig. auch genau so wie du es geschrieben hast @akaretschmer, bin schon völlig matsche in der Birne.
Versuche das mal so abzuändern und melde mich noch mal, Danke!

 

[castorp]

Grundsätzlich ist sowas viel einfacher (und flexibler) in der Anwendung (oder Reporting Tool) zu machen.

SQL ist dafür einfach nicht entworfen worden

 

[dabadepdu]

SQL ist dafür einfach nicht entworfen worden

OT
Ja, leider, aber ich sehe eigentlich keinen Grund, dass es nicht komfortabel angeboten/umgesetzt wird. Und zwar nicht nur schnödes Pivot/Unpivot mit zahlreichen Limits.
Das Reporting Tool macht ja am Ende auch nichts anderes, als SQL abzusetzen.

Nimmt man bspw. "Window Functions" könnte man auch sagen, dafür ist SQL oder sogar RDBMS -mit Sicherheit!- nicht entworfen worden.
Aber es gibt sie trotzdem. Mir ist klar, dass die dynamische Handhabung von Spalten (bzw. on-the-fly Persistierung dynamischer Spalten) wirklich nicht das Kerngeschäft von SQL ist. Am Ende ist es aber nichts anderes als der Output dynamischer Spalten wie bei einem beliebigen Join.
Window Functions "überwinden" ein zwar anderes, aber ebenfalls gravierendes, grundsätzliches Functionsprinzip von SQL.
/OT

 

[castorp]

Am Ende ist es aber nichts anderes als der Output dynamischer Spalten wie bei einem beliebigen Join.

Nicht ganz. Die Ergebnisspalten eines JOINs stehen vor der eigentlichen Ausführung der Abfrage fest (so wie deren Namen und Datentypen). Bei einem PIVOT ist das nicht der Fall. Die Spalten (Namen, Datentypen) würden erst während der Ausführung (beim Lesen der Daten) verfügbar sein. Das widerspricht dem grundlegenden Design einer relationalen Datenbank.

Window Functions widersprechen diesem Funktionsprinzipe auch nicht. Sie operieren auf Spalten die vor der Ausführung bekannt sind und die aus Zeilen kommen, die sowieso gelesen werden. Die Daten/Zeilen die ein select id from some_table aus einer Tabellen lesen muss, sind die gleichen die ein select id, row_number() over (order by id) from some_table lesen muss. Der Zugriff auf "vorherige" bzw. "folgende" Zeilen (via lag() oder lead()) wird letztendlich dadurch erreicht, dass die benötigten Zeile im Speicher gehalten werden (anstatt sie an den Aufrufen zu schicken und dann "weg zu schmeissen"). Aber auch hier ist vor der Ausführung klar, welche Spalten das sein werden.

 

[dabadepdu]

OT Wahrscheinlich wird das wieder gestrichen, wenn wir so weiter machen
Ich habe die Window Functions nicht angeführt, weil sie ein identisches, technisches Problem darstellen, sondern weil sie wie PIVOT funktionale Grundlagen oder Ideen von SQL "ignorieren", besser überwinden und eben auch existieren. Obwohl es nie dafür gemacht war. Also einfach als Beispiel dafür, dass SQL niemals dafür gedacht war, aber es trotzdem eine gute Umsetzung gibt.

Gut, die Problematik bei PIVOT ist eine andere, als bei meinem "Gegenbeispiel".
Wie auch immer die herstellerspezifische Implementierung der SQL Engine aussieht, wenn es um Kenntnis der Spalten vorher / nachher geht:
Ich weiß nicht die Menge der Spalten, aber ich weiß den Typ und ich weiß, dass es immer der gleiche ist.
Fehlt eine simple Namensdefinition / Vorgabe für die "unbekannten" Spalten, so funktionieren nach meiner Kenntnis eben auch aktuell vorhandene Implementierungen.

Was ich an dem Status Quo bedauerlich finde, vielmehr an der Lösung: "mach es im Frontend/Report Tool" wie von Dir und mir vorgeschlagen, es widerspricht dem Serverprinzip. Clientlösungen erfordern oft deutlich höheren Datenverkehr, die berühmte If Schleife und so Kram. "Lade einfach eben die ganze Tabelle runter, überleg noch ein bisschen und dann gib es aus oder wirf es weg". (Und frag bitte nicht so blöd, warum es so lange dauert)

Dynamic Table Functions gibt es ja bereits und in PG bspw. ist ja die Pivot Fähigkeit auch über eine Function realisiert. Da könnte noch was gehen.

Ich sag mal so: Der ein oder andere Anbieter hat ja "PIVOT" im Programm. Aber ich sehe da noch Potential. Bloß zu konstatieren, dafür wurde SQL nie gemacht, verschenkt das Potential.
/OT

 

[castorp]

Der ein oder andere Anbieter hat ja "PIVOT" im Programm.

Ja, aber auch da ist die Anzahl der Spalten fest und muss vor der Ausführung definiert werden. Der PIVOT Operator macht das nur ein wenig einfacher als ein CASE Ausdruck.

Viele (die meisten?) Frontends sind heute Web basiert. Für die kann man z.B. die dynamischen Spalten in ein JSON Objekt aggregieren. Sowas lässt sich via HTML extrem einfach als Tabelle anzeigen. Damit hättest Du die Logik des "PIVOT" bzw. der Aggregation auf der Serverseite und die "Logik" der Anzeige im Client

 

[dabadepdu]

aber auch da ist die Anzahl der Spalten fest und muss vor der Ausführung definiert werden. Der PIVOT Operator macht das nur ein wenig einfacher

OT
Richtig, ein wenig einfacher macht er es.
JSON oder XML als Ausweg sind auf jeden Fall eine pragmatische Lösung für das Darstellungsproblem.

Ich bleibe dennoch bei der Frage hängen, warum es nicht komfortabler angeboten wird.
/OT