dynamisches "verschieben" von werten in spalten

[kraeppy]

hallo zusammen,

es geht um folgendes:
in einer tabelle werden für diverse produkte für jeden tag 100-viertelstundenwerte hinterlegt (100 wegen der zeitumstellung).

wir haben zwei systeme. in dem einen liegen die daten in unterschiedlichen zeiten (zb türkische, kolumbianische etc) vor. z.b. türkische zeit 2:00 wäre in der tabelle die 8. viertelstunde.
im zweiten system sind die daten NUR in mitteleuropäischer zeit.

jetzt kam eine anforderung, dass für gewisse produkte die 100-viertelstundenwerte in das zweite system importiert werden sollen ALLERDINGS mit mitteleuropäischer zeit.

MEZ (utc+1) und türkische zeit (utc+3) unterscheiden sich lediglich um 1h. d.h. für tag x müssten die viertel-stunden-werte um 4 spalten nach links verschoben werden.
bei utc+5 müssten entsprechend die werte um 16 spalten verschoben werden.

mein problem ist, dass ich nicht weiß, wie ich das am geschicktesten lösen kann. denn beim "verschieben" würden ja manche werte in den vortag bzw. in den nächsten tag rutschen (abhängig natürlich von der jeweiligen UTC zeit).
die einzige idee, die ich im moment habe, ist so nach dem motto:

val_10 = case UTC_DIFF when 1 then val_14
case UTC_DIFF when 2 then val_16... und so weiter und so fort. aber eben hierbei wüsste ich net, wie ich das verschieben in den nächsten tag/vortag

kann mir jemand einen tipp geben, wie ich da am besten herangehen kann? meine idee, die ich hatte, würde ich nämlich nicht umsetzen wollen, weil es dann für jeden viertelstunden werte 23-case-bedingungen hätte und das sieht - auf gut deutsch gesagt - shitte aus ^^

danke im voraus und

lg

kraeppy

 

[akretschmer]

Ähm. Zur Klarstellung: ihr habt da also 100 Spalten, jede Spalte steht für eine viertel Stunde, ja? Das ist ein vollständig kaputtes Design. Korrekt wäre, die Zeit mit Zeitzone zu speichern, dann würden sich schlagartig alle Eure Probleme in Luft auflösen. Ich denke, nun ist der optimale Zeitpunkt, das Problem final zu beheben, oder?

 

[ukulele]

Ich stimme zu. Was du machst hat nichts mit relationalen Datenbanken zu tun sondern ist Tabellenkalkulation und nebenbei noch so massiv kaputt, da sind 23 CASE-Anweisungen noch harmlos.

 

[kraeppy]

da geb ich akretschmer völlig recht. die tabelle existiert seit zig jahren und damals war es so, dass diese problematik nicht berücksichtigt wurde... ich arbeite auch hier erst seit knapp 2 jahren ^^
nichtsdestotrotz muss ich die daten eben wie beschrieben aufbereiten.

ich werde das jetzt so lösen, dass ich mir einen cursor definiere, mir für zwei tage die werte in variablen packe und dann mein result-table mit entsprechender logik befüllen.

@ukulele: "massiv kaputt" bezieht sich auf die vorhandene struktur der tabelle oder dem vorhaben die daten aufzubereiten?

 

[ukulele]

Auf die Struktur, jedes Query was diese Struktur nutzt wird zwangsläufig sehr umfangreich und unübersichtlich.