Byłoby znacznie lepiej, gdyby daty były przechowywane jako daty. Przechowywanie ich jako liczb, a nie jako ciągów, wprowadza inny zestaw problemów.
Jeśli całkowicie utkniesz z datami przechowywanymi jako ciągi, aby umożliwić użycie indeksów w kolumnach, musisz przekonwertować daty używane jako parametry na ciągi w odpowiednim formacie, a następnie polegać na fakcie, że sortowanie ciągów w tym konkretnym formacie jest zgodne z oczekiwaną kolejnością sortowania rzeczywistych dat. Jeśli kiedykolwiek porównasz ciąg z datą lub liczbą, uzyskasz niejawną konwersję typu danych, która w najlepszym przypadku doprowadzi do problemów z wydajnością, ponieważ nie można użyć indeksów, a w najgorszym przypadku wygeneruje nieprawidłowe wyniki lub błędy.
Zakładając, że unikniesz konwersji typu danych, problemy z wydajnością mogą wynikać z faktu, że optymalizator ma duże trudności z oszacowaniem kardynalności, gdy użyjesz niewłaściwego typu danych. Oracle wie na przykład, że między 01.01.2012 a 01.01.2013 jest 365 dni (czyli 8760 godzin lub 525600 minut). Z drugiej strony istnieją miliardy możliwych ciągów między „20120101000000” a „20130101000000”. Może to spowodować, że optymalizator nie użyje indeksu, kiedy tego chcesz (lub odwrotnie), użyje złego rodzaju złączenia itp.
