Putzige Sachen: Datum im Neuner-Komplement

March 5, 2010 by · 1 Comment
Filed under: Deutsch 

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 …