Би било много по-добре, ако датите се съхраняват като дати. Съхраняването им като числа, а не като низове, въвежда различен набор от проблеми.
Ако сте напълно блокирани с дати, съхранени като низове, за да разрешите използването на индекси на колоните, ще трябва да конвертирате датите, които използвате като параметри, като низове в подходящия формат и след това да разчитате на факта, че сортирането на низове в този конкретен формат съответства на очаквания ред на сортиране на действителните дати. Ако някога сравните низа с дата или с число, ще получите имплицитно преобразуване на тип данни, което в най-добрия случай ще доведе до проблеми с производителността, тъй като индексите не могат да се използват, а в най-лошия ще генерира неправилни резултати или грешки.
Ако приемем, че избягвате преобразуването на типове данни, проблемите с производителността вероятно ще възникнат от факта, че оптимизаторът изпитва големи затруднения при оценяването на кардиналността, когато използвате грешен тип данни. Oracle знае, например, че има 365 дни (или 8760 часа или 525600 минути) между 1/1/2012 и 1/1/2013. От друга страна, има милиарди възможни низове между „20120101000000“ и „20130101000000“. Това може да накара оптимизатора да не използва индекс, когато искате (или обратното), да използва грешен вид присъединяване и т.н.
