Regional unterschiedliche Datumswerte speichern?

W

Wonka

Benutzer
Beiträge
17
Hallo zusammen,

für ein Datawarehouse bin ich gerade am Überlegen, wie man regionsspezischische Datumswerte am besten speichert. Hintergrund ist, dass wir eine Tabelle für Datumsdimensionen haben. Diese ist aus Performancegründen auf x Jahre vorberechnet und enthält z.B. den Wochentag, auch als nummerischen Repräsentanten. Bei uns wäre das Montag = 1, Dienstag = 2, Mittwoch = 3,... Zudem die Info, in welcher Jahreszeit ein Datum liegt.

Nun ist es ja von "Region zu Region" bzw. Nord- zu Südhalbkugel unterschiedlich, ob der Montag oder der Sonntag der 1.Tag der Woche ist oder, ob z.B. im Juli Sommer oder Winter ist.

Ich hoffe, ihr versteht, was ich meine. Auf die Daten wird mittels Geschäftsanalyse-Werkzeug wie Tableau, Power Bi, o,ä. zugegriffen. Das heißt, die Benutzer haben es im Grunde auch selbst in der Hand, welche Spalte sie sich anzeigen lassen.

Alles in allem gibt es nur eine Instanz der DB, d.h., über Regioneneinstellungen ist da nichts zu machen. Wie löst man sowas? Macht man dann z.B. eigene Spalten, einmal mit unseren hiesigen nummerischen Wochentagen und eine für am Sonntag beginnende Wochen? Jahreszeiten für Süd- und Nordhalbkugel? Oder gibt es da schönere / bessere Varianten?

Wenn ich im Netz danach suche wird immer von einer on-the-fly-Berechnung ausgegangen, also zum Zeitpunkt des Datenabrufs durch den Benutzer, aber das wäre bei unseren Datenmengen nicht geeignet.

Ich bedanke mich schon mal!
 
Werbung:
Hatte das Problem selber noch nicht, würde in diesem Spezialfall aber wirklich mit eigenen Spalten arbeiten. Je nach Datenbank, die Du verwendest, sind ev. materialized views auch noch ein Thema.
 
Welche DB / Client Du verwendest ist ja nicht bekannt. Es gibt Clients, die entsprechend ihrer Locale Settings mit den richtigen Anworten versorgt werden, vorrausgesetzt sie sind richtig installiert.
Das Problem gibt es ja nicht nur bei Wochentagen, sondern bereits bei Uhrzeiten in verschiedenen Zeitzonen, Datumsgrenzen ..
 
Danke euch.

Die DB ist Postgres. Der "Client" ist nicht einheitlich. Wie geschrieben ist das Tableau, Power Bi oder ein anderes Geschäftsanalyse-Werkzeug. Da haben wir keinen Einfluss drauf, wir stellen nur das Datawarehouse.
 
Danke dir. Ich gebe dir definitiv Recht, dass solche Formatierungen Sinn ergeben, wenn man selbst die Abfragen schreibt und/oder für eine Vorabberechnung.

Wie aber soll das funktionieren, wenn du eine DB für mehrere Regionen hast und dir die Spalten, die du sehen willst, zusammenklickst? Es soll ja nicht für jede Ansicht, die eine von einem Datum abgeleitete Information enthält in Sql erstellt werden, dazu noch mit dem Wissen, wie man das Datum sich entsprechend formatiert. Die Anwender sind Analysten, keine DB-Experten.

Oder wie genau kann das deiner Meinung nach funktionieren, dass Benutzerabhängig (wir gehen davon aus, dass ein Benutzer immer seine feste Region hat und sich nicht heute Daten von der Nord- und morgen von der Südhalbkugel anschaut; das ist bei uns nicht der Fall) die Daten anders angezeigt werden? Vermutlich bin ich dazu auch nicht tief genug in PG und diesen Geschäftsanalyse-Werkzeugen drin.
 
Nun ja, Du hast damm vermutlich mehrere User. Du kannst bestimmte Variablen wie datestyle per User setzen, Du kannst auch eigene Variablen definieren, innerhalb einer Session. Das kannst Du so nutzen:

Code: 
postgres=# select * from blabla ;
 id | userid 
----+--------
  1 |      1
  2 |  12345
(2 rows)

postgres=# set session "myapp.user" = '12345';
SET
postgres=# select current_setting('myapp.user');
 current_setting 
-----------------
 12345
(1 row)

postgres=# select * from blabla where userid = current_setting('myapp.user')::int;
 id | userid 
----+--------
  2 |  12345
(1 row)

postgres=#
 
Ich glaube, ich würde das anders angehen.

In der Tabelle wird das immer nach ISO gespeichert (Also 1=Montag).

Dann würde ich ein Funktionen schreiben, die regionale Werte nach ISO umrechnet.

In der Abfrage wird dann etwas in der Art wie where weekday = convert_to_iso_dow('US', 1) verwendet. Der Anwender kann dann z.B. mitgeben in welchem System die Benutzereingabe erfolgt ist ('US')
 
Mmh, also ich bin mir nicht sicher, welches Problem da gelöst werden soll.
In der Praxis betreue ich kein System/ Software, das diese Problematik hat (außer dass die Strecke OS > Browser > AppSer > DB schon konstistente Auswertungen ergeben sollte, wenn jemand alle Daten von "Heute" auswerten möchte, egal wo er auf der Welt sitzt). Also ein paar Überlegungen dazu:

Wie gesagt, regionale Unterschiede gibt es bereits bei Uhrzeiten und das dürften nicht unwesentlich viele Vorkommen sein. Vielleicht hat ein DWH keine Uhrzeit Genauigkeit, aber 2x am Tag, am Anfang und am Ende spielt die Uhrzeit in den Tag rein...

Welchen Sinn macht es, wenn der Ami auf andere Kalenderwochen schaut, als der Russe oder der Inder oder der EMEA Fuzzi und jeder mit anderen Zahlen um sich wirft, weil Oktober halt überall andere Grenzen hat?

Ich mein, das ist doch der Grund, warum es so ein Sch.. wie SAP gibt. Man muss sich darauf einigen, welche Zeiträume man betrachtet und bewertet, wann Tagesabschluss ist, Monat-, Quartal- usw.

In der DB würdest Du doch wahrscheinlich sowas wie Datetime nach UTC haben. Und wer dann da aus lokaler Perspektive drauf schauen möchte, soll es halt machen...
 
Werbung:
dabadepdu schrieb:
Welchen Sinn macht es, wenn der Ami auf andere Kalenderwochen schaut, als der Russe oder der Inder oder der EMEA Fuzzi und jeder mit anderen Zahlen um sich wirft, weil Oktober halt überall andere Grenzen hat?
Zum Vergrößern anklicken....
Deinen Einwand kann ich verstehen. Es ist allerdings nicht so, dass "der Ami" und "der Russe" die gleichen Zahlen anschauen. "Der Ami" schaut sich die amerikanischen Zahlen an, "der Russe" die russischen Zahlen. Beide Zahlen stehen in keinem Zusammenhang und müssen darüber hinaus auch getrennt aufbewahrt werden, so dass weder der eine, noch der andere auf die Zahlen des jeweils anderen zugreifen kann.
Es gibt dazwischen aber eben in einem separaten Schema auch allgemeine Tabellen, wie für Datum und Zeit, da diese zu größten Teilen ja gleich sind.

Wir werden es jetzt so machen, dass wir alle Datumswerte in ISO 8601 speichern.
 
Zurück
Oben