Putzige Sachen: Datum im Neuner-Komplement

Für englisch-sprachige Leser: There is an English version of this post.

 
Forto von Picture Taker 2, flickr.com

Dies ist ein Eintrag, aus dem hoffentlich eine ganze Serie von putzigen Sachen wird, die mir so über den Weg laufen: Seltsame Formate, Verschlüsselungen oder Datenmodellierungs-Entscheidungen.

Dieser Eintrag beschreibt ein Datumsformat, das wir als ‘Neuner-Komplement’ bezeichnen. Ich konnte dazu nichts bei Wikipedia finden, und Google lieferte nur einen Verweis auf eine obskure IBM-Dokumentation.

Beobachtung

In einer SAP Maske gab es ein Datumsfeld “Gültig Bis”. Hier kann man ein Datum eingeben, bis zu dem eine Information gültig ist (z.B. bis ‘31.12.2006’). In der Datenbank konnten wir schnell eine ‘VALIDTO’ Spalte finden, dort standen aber seltsame Werte wie ‘79938768 ‘, die nicht wie ein Datum aussahen. Die Spalte war als CHAR(8) definiert, was nicht ungewöhnlich für Datums-Felder ist: Speichert man das Datum im Format ‘YYYYMMDD’, so kann man mit einer normalen numerischen Sortierung auch die entsprechenden Daten (Datümer 😉 ?) sortieren. In diesem Fall wäre das obige Beispiel-Datum als ‘20061231’ abgelegt.

Es hat eine Weile gedauert, bis wir hinter die seltsamen Werte in der Datenbank kamen: Man muss dann YYYYMMDD von 99999999 abziehen. Hier ist die vollständige Ableitung:

Datum 31.12.2006
im Format YYYYMMDD 20061231
   
8 Neunen 99999999
minus formatiertes Datum 20061231
Datum im Neuner-Komplement 79938768

Wenn man die Werte in der Datenbank wieder in das richtige Format konvertieren will, kann man die gleichen Schritte in umgekehrter Reihenfolge durchführen (d.h. wenn man den Wert von 8 Neunen abzieht, erhält man ein Datum im  YYYYDDMM-Format).

Und wozu ist das gut?

Auf Nachfragen wurde folgende Erklärung für dieses Format geliefert: Das neuste Datum steht so an erster Stelle, so dass man damit eine absteigende Sortierreihenfolge simulieren kann, wenn diese nicht direkt unterstützt wird, etwa bei der Definition von Indices.

Dies könnte durchaus sein, schließlich ist dieses Format im SAP Kontext aufgefallen und SAP hat eine komplexe Abstaktionsschicht über die verschiedenen Datenbanksysteme gelegt. Ich hege immer noch die Vermutung, dass die SAP eine datenbankunabhängige Indizierung der Datenbank implementiert hat, auch wenn heute SAP-Indices in der Regel direkt auf der Datenbank umgesetzt werden.

Mir ist aber nicht klar, wozu die Definition einer absteigender Reihenfolge in einen Index wichtig sein soll. Ich habe eine Frage auf StackOverflow dazu gestellt, und die Antworten darauf schildern ziemlich obskure Situationen. Solange Sachen wie Cluster-Tabellen keine Rollen spielten, sollte die Reihenfolge eines Index nicht wichtig sein. Egal ob man eine Sortierung mit ORDER BY, eine Suche nach einem Wert mit binäre Suche oder dem Durchwandern eines B-Baum vornimmt, sollte die Sortierreihenfolge keinen wesentlichen Einfluss auf die Leistung haben.

Es wäre sehr interessant, die Performance einer "normalen" Ablage als Datum und eines aufsteigenden Indexes auszuprobieren. Ich bin mir ziemlich sicher, dass man heutzutage keine großen Unterschiede feststellen kann. Vermutlich gibt es für dieses Format also nur Gründe, die heute nicht mehr zutreffen. Wahrscheinlich stammt das Format werden von einigen "alte COBOL-Mainframe-Programmierern" aus den Tagen, als man nur sequentiellen Zugriff auf eine Band-Datei zur Verfügung hatte …

Comments

One Comment on Putzige Sachen: Datum im Neuner-Komplement

  1. Rüdiger on Wed, 27th Aug 2014 11:12
  2. Ich bin gerade über dasselbe Thema gestolpert, als ich einen QuickView erstellt habe. Das ungewöhnliche Format hat eine ältere Kollegin sofort erkannt und gesagt: “vielleicht musst Du ein Reverse-Datum haben, indem Du das von 99999999 abziehst”. Das scheint mir wirklich aus alten Tagen zu stammen.

    Warum aber der Kommentar: ich benötige die VALIDTO-Spalte einer Tabelle als Abgrenzung für meinen QuickView. Deshalb habe ich sie als Selektion mit aufgenommen. Führe ich den QuickView nun aus und gebe z.B. an, die Angabe “Gültig bis” soll größer (>) 26.08.2014 sein, also mindestens bis heute gültig oder länger, dann selektiert der QuickView trotzdem alle Datensätze aus der Tabelle.
    Also habe ich gedacht, ich nutze für die Selektion ein Intervall und habe in das linke Feld (Untergrenze) 27.08.2014 und in das rechte Feld (Obergrenze) 31.12.9999 eingegeben. Was sagt SAP dazu?

    “Untergrenze größer Obergrenze”

    Also habe ich die Angaben in den Feldern der Selektion umgedreht und, siehe da, die Abfrage mit Untergrenze 31.12.9999 und Obergrenze 27.08.2014 hat anschließend korrekt funktioniert und das gewünschte Ergebnis geliefert. Ich leite daraus folgende Erkenntnis ab: wenn man ein solches Datumsfeld vorfindet, dreht man die Verwendung konsistent an allen Stellen um 🙂

Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!