In Cost Based Oracle hat Jonathan Lewis dieses Thema bereits umfassend erläutert: Datumswerte sollten mit dem Datentyp DATE gespeichert werden, da der Optimizer nur für diesen Datentyp das Wissen besitzt, dass es zwischen den Monats- und Jahreswechseln keine großen Lücken gibt - dass also auf to_date('31.12.2016', 'dd.mm.yyyy') als nächster Tag to_date('01.01.2017', 'dd.mm.yyyy') folgt; und nicht 20161232 nach 20161231. Insofern enthält die aktuelle Artikelserie von Richard Foote zum gleichen Thema keine grundsätzlich neuen Einsichten, aber lesenswert sind die Artikel des Herrn Foote immer und man kann bei Bedarf gut darauf verlinken, so dass ich sie hier einfach aufliste:
- Storing Date Values As Characters (What’s Really Happening): erklärt, warum man Datumsangaben nicht als Strings speichern sollte.
- Storing Date Values As Characters Part II (A Better Future): zeigt, wie man die Probleme mit den char-Werten durch Ergänzung eines FBI reduzieren kann.
- Storing Date Values As Numbers (The Numbers): erläutert die Konsequenzen der Speicherung von Datumswerten mit dem Datentyp NUMBER.
Keine Kommentare:
Kommentar veröffentlichen