Tabelle transponieren? /Matrixformat

Andey

Benutzer
Beiträge
13
Hallo,
da ich hier mittlerweile schon dreimal perfekte Hilfestellung bekommen habe, wende ich mich mal wieder hoffnungsvoll an euch...

Ich habe gerade eine Tabelle, die ungefähr so aussieht:

Liefer_1 | Liefer_2 | Liefer_3 | ... | Liefer_53
bürste NO YES NO NO
gel YES YES NO NO
kamm NO NO NO YES

Liefer_1 steht für KW1. Somit weiß ich also, dass die Bürste in Kalenderwoche 2, das Gel in 1 und 2 und der Kamm in KW53 geliefert wurde.

Ich benötige die Ausgabe als schnöde Liste.
Dieses Format wäre wünschenswert:
Artikel | KW
bürste 2
gel 1,2
kamm 53

Meine Idee wäre es erst einmal ein Transponieren der Tabelle. (Allerdings handelt es sich um weit mehr als 100.000 Datensätze da könnte das dann schon extrem langsam werden, oder?) Aber um ehrlich zu sein, übersteigt die Komplexität hier meine geringen SQL-Fähigkeiten.

Ein Tipp, wie das Ganze (wie immer ohne Schreibrechte) zu bewerktstelligen ist, wäre super, falls eine Umsetzung in Oracle 10g überhaupt machbar ist
 
Werbung:
Hab jetzt Deine spezifische Historie / Anforderungen nicht im Kopf.

Also ganz schnöde ist die Liste nicht, sie enthält das Aggregat der Lieferwochen.
Wenn Du Oracle 11 hättest, könntest Du unpivot nutzen.
Mit Oracle 10 ist es erstmal einfach ein Union Statement, das jeweils den Artikel und die nächste Lieferwoche ausliest. Das ist auch nicht komplex, eher langweilig und unelegant und ineffizient.

Code:
(create view schnoede_liste as)
Select artikel, 1 as KW from sourcetable where liefer1='Yes'
union
Select artikel, 2  from sourcetable where liefer2='Yes'
...

(create view aggr_liste as)
select artikel, string_agg(kw) from schnoede_liste group by artikel;
Hier einige Tipps zu string_agg und anderen (direkten) Ansätzen, die für Dich u.U. auch in Frage kommen.
Hier dämmert mir, dass es auch Dein Problem war ...
 
p.s.:

100000 Datensätze ist ja nicht so schlimm, aber der Union würde das natürlich x mal (je Spalte) abfragen. Vielleicht besser ein Case Statement ..
Ist das mit den KW real oder ein Beispiel, also x=53, statisch oder kann das auch variieren? (Solche Transformationen sind ja gerne variabel)

In welchem Kontext rufst Du das auf?
- Client, Eigenproduktion
- Script, Eigenproduktion
- Analysetool, Onetime, Migration, Export, Cloud, Remote ..
 
Hallo,
erstmal vielen Dank für die schnellen Antworten. Ich werde mich heute Abend mal dran setzen.
Das Problem ist leider real und nicht nur theoretisch, allerdings kann ich durch vorherige Auswahl der Artikel, die Datensätze enorm reduzieren... in der Liste benötige ich nur diejenigen, die gratis geliefert werden und von der aktuellen KW in die Zukunft. Damit reduziert sich das Ganze auf 79 Datensätze, was performancetechnisch durchaus machbar sein sollte xD. Ich habe bisher nur noch nie das Ergebnis einer Abfrage als Grundlage für eine neue verwendet - ich mag hier aber auch nicht zu viel fragen, ohne es vorher mal ausprobiert zu haben.
Eine weitere Frage wäre aber, ob man die aktuelle KW über eine Datumsfunktion ermitteln kann - alles bisher gefundene erfordert neuere Datenbankversionen oder die Möglichkeit Funktionen anzulegen.

Derzeit rufe ich alles über einen Client auf. Mittelfristiges Ziel ist, für alle Abfragen irgendwann mal ein einfaches Frontend in Java zu basteln.

Bevor ich mit den Abfragen begonnen habe, wurden Excellisten gedruckt und per Hand geführt -also selbst ohne FrontEnd bin ich sehr glücklich über die Möglichkeiten von SQL (die benötigten Daten sind ja tatsächlich schon vorhanden, man kommt über das eingesetzte Programm (Eigenproduktion ohne die Möglichkeit, jetzt noch etwas daran zu verändern) nur nicht dran)

Also schon mal vielen Dank für die erneute Hilfestellung
 
Das aktuelle Datum bekommt man über
sysdate
Der Rest ist eine Frage der Formatierung
select to_char(sysdate,'iw') from dual;
wobei
ParameterExplanation
WWWeek of year (1-53) where week 1 starts on the first day of the year and continues to the seventh day of the year.
WWeek of month (1-5) where week 1 starts on the first day of the month and ends on the seventh.
IWWeek of year (1-52 or 1-53) based on the ISO standard.
Du solltest bei der Abfrage bzw. den Abfragekriterien darauf achten, dass ggf. vorhandene Indizes genutzt werden.

Meine Frage nach der "Realität" drehte sich nur darum, den Sachverhalt besser zu verstehen.

btw: Was Du schreibst, klingt so als ob man sich unnötig quält. Wenn man dauerhaft die Aufgabe hat oder vergibt, ein System und seine Nutzung zu verbessern, warum dann mit so vielen Krücken? Aber vielleicht muss es noch mehr weh tun, damit etwas geändert wird.
Ist die DB grundsätzlich schreibgeschützt, nur für Dich als mglw. Freelancer, ... gibt es evtl ein separates, beschreibbares Schema (hat sowieso jeder Nutzer)? Die Möglichkeit pl/sql einzusetzen und Zwischenergebnisse zu speichern, kann jedenfalls sehr nützlich sein und die Effizienz steigern (schnellere Ergebnisse, weniger Auslastung)
 
Derzeit rufe ich alles über einen Client auf. Mittelfristiges Ziel ist, für alle Abfragen irgendwann mal ein einfaches Frontend in Java zu basteln.
Client = SQL Tool? Also auch SQLPlus / Scripting?
Jedenfalls kein interaktives Programm für die Anwender?

Auch eine kleine Ergebnismenge kann ewig dauern, wenn die Bedinungen (auch Where Bedingungen) hinreichend ungünstig und die Datenmenge groß ist. Deine "Tabelle" die Du abfragst, hört sich ja nicht nach einer regulären an, klingt irgendwie nach Reporting oder DWH. Evtl. gibt es gar keine Indzies dort?
Im Grunde ist es nicht unwahrscheinlich, dass Du die Daten aus dieser Matrix an anderer Stelle als Tabellen oder Abfragen findest. Denn in der Regel sind das Ergebnisse einer Datenverarbeitung und nicht die Datenhaltung selbst.

Je nach Zugriffsmöglichkeiten gäbe es noch andere Möglichkeiten, per Scripting und separater Datenaufbereitung, quasi export (relevanter Daten = hier 79 records).
 
Guten Morgen,

natürlich habe ich gestern nach der Montage von Fussbodenleisten gar nichts mehr hinbekommen, außer zu schlafen - aber das nur am Rande.

Hintergrund meiner ganzen Fragen ist folgender:
In unserem Betrieb gibt es ein eigens entwickeltes CRM, geschrieben in Omnis Studio, gewachsen über ein Jahrzent, dann verstarb der Entwickler und mit ihm das Wissen über den zwar vorhandenen aber dürftig dokumentierten Quellcode.
Da sich das Tool über die ganze Firma zieht und zum großen Teil alles darüber abgewickelt wird, hat sich seither niemand mehr gewagt, etwas daran zu verändern.

Vor sechs Monaten kam ich dazu (allerdings bin ich Verkäufer und kein Freelancer) und habe mich gewundert, dass viele Dinge aus meiner Sicht unnötig kompliziert angegangen werden.
Nach Rücksprache mit unserem IT-Experten bekam ich dann Lesezugriff auf die darunterliegende Datenbank, um wenigstens einige Dinge abfragetechnisch noch etwas zu optimieren.

Da dies in verschiedenen Abteilungen der Fall ist, sind die Aufgabenstellungen auch sehr unterschiedlich und ich kann sie erst nach und nach neben meiner eigentlichen Arbeit abarbeiten.

Ein Wechsel des CRMs ist momentan nicht geplant, die Neuentwicklung ebenso teuer wie der Kauf der führenden Branchenlösung und Freelancer, die sich mit Omnis auskennen, nicht gerade wie Sand am Meer vorhanden xD

Von daher besteht im Moment nur die Möglichkeit mit dem zu arbeiten, was vorhanden ist.

Die Daten der KWs sind tatsächlich nur an dieser Stelle gespeichert - eine Abfrage dazu gibt es vermutlich versteckt im Quellcode des Ursprungsprogrammes - allerdings dann noch ohne Umsetzung ins GUI.

Als SQL Tool verwende ich den dBeaver 23.03.5 auf einem Mac mit OS 10.12 (und auch das ist eine Sache, die ich so als gegeben akzeptieren muss 🥲) - für meine Zwecke funktioniert das aber erschreckend gut.

Hoffentlich komme ich heute Abend zu einem Test - dann auch mit dem Versuch die KW mit einzubauen - vielen Dank für die Infos dazu!

Schönen Sonntag!
 
Omnis Studio hab ich noch nie gehört, aber scheint ja jemand bei Euch zu geben, der Apple Fan ist.
Ich hatte vermutet, das ist Zeug aus dem 20 Jahrhundert, aber es scheint ja aktuelle Versionen zu geben. Wieso macht man an der Stelle nicht weiter, statt sich freiwillig auf diese Zumutungen zu beschränken?
Alternativ, der Einstieg in den Ausstieg wie bereits vorgeschlagen: Ein zweite, freie DB, die man nur für Auswertungszwecke nutzt und darin alles machen kann, was man mag. Datenabgleich nächtlich oder nach Bedarf und dann freie Hand für alles was man will (auch das ginge sogar mit Omnis wenn ich das richtig sehe, sogar umsonst in der einfachsten Edition.

eine Abfrage dazu gibt es vermutlich versteckt im Quellcode des Ursprungsprogrammes - allerdings dann noch ohne Umsetzung ins GUI.
Das habe ich nicht verstanden. Den "Report"/die Daten muss man doch wohl irgendwo einsehen können, abrufen, aktualisieren?
 
Hier mal noch zwei Hinweise.

1) Es gibt durchaus unterschiedliche Zählweisen für die Kalenderwoche. Das ist teilweise länderspezifisch, aber wenn dein CRM irgendwann mal selbst gecodet wurde, könnten da alle möglichen Fehler drin stecken. Du solltest daher mal prüfen, wann KW1 anfängt und wann die letzte KW aufhört. Klingt banal, ist es aber nicht :)

2) So ein altes System bringt viele Probleme mit sich. Wenn du keine Kosten produzieren darfst, aber quasi Zeit da rein stecken kannst, könntest du überlegen mit Triggern sowas wie Schattentabellen so pflegen. Du würdest dann immer bei Änderungen der eigentlichen Tabellen eine vernünftig normalisierte Tabelle aktualisieren, ohne die eigentliche Funktion der Software zu beschränken.
 
Vielen Dank für die großartige Unterstützung. Habe meine neue Abfrage hinbekommen - mit CTE, da Create View ja nicht funktioniert und mit Abfrage von der aktuellen Kalenderwoche.
So hat die Abfrage eine Laufzeit von 5 Sekunden, was durchaus annehmbar ist.
Danke auch für den Hinweis mit den KWs - allerdings ist das in unserem speziellen Fall (oder gerade jetzt) kein Thema für mich, da die letzte und die ersten beiden Wochen im Jahr bei uns sowieso nichts passiert - aber ich habs abgelegt und auf dem Schirm, wenn ich weiter mit Kalendewochen arbeiten muss.

@dabadepdu
Leider ist deine Vermutung schon ganz richtig - das Zeug stammt sowas von aus dem 20. Jahrhunder xD
Das ist der Grund weshalb wir die Laufzeitumgebung 6.1.3 x86 verwenden, da hier das Programm noch läuft ohne es an neuere Omnis Versionen vom Programmcode her anpassen zu müssen. Diese Runtime läuft aber nicht auf akutellen Mac OS- Versionen (deshalb die 10.12).
Und bis sich die Katze irgendwann in den Schwanz beißt, mag ich uns das Leben wenigstens ein bisschen erleichtern, so gut das eben geht.

Die Idee mit der freien DB / Schattendatenbank mit nächtlicher Aktualisierung oder Triggern finde ich durchaus interessant.
Im Moment denke ich aber, dass hier der Aufwand den Nutzen (die neue DB wäre ja ausschließlich für mich im Moment) noch bei Weitem übersteigt.

Aber auch das behalte ich mal für die Zukunft im Hinterkopf.

Danke nochmal eure Hilfe!
 
Werbung:
die neue DB wäre ja ausschließlich für mich im Moment
Jein, sie würde für Reports taugen (die Du vielleicht, aber auch Deine Kollegen gebrauchen können).

das Zeug stammt sowas von aus dem 20. Jahrhunder
Ja, aber wieso bleibt man da stehen?
Es gibt doch aktuellere Versionen. Sind die Brüche so groß, dass sie eine Umstellung verhindern?

Man darf ja vielleicht auch mal fragen, was eine "eingefrorene" Software mit der Produktivität macht. Wenn alles nur noch daran hängt, ob es mit der Software von 1998 geht, dann muss das doch richtig Geld kosten, die ganzen Workarounds oder sogar Nogos wegzuatmen.

Wie auch immer, man macht es sich nicht leichter, wenn man jahrelang nichts tut.
 
Zurück
Oben