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 …
Leave a Reply