Sería mucho mejor si las fechas se almacenaran como fechas. Almacenarlos como números en lugar de cadenas presenta un conjunto diferente de problemas.
Si está absolutamente atascado con las fechas almacenadas como cadenas, para permitir el uso de índices en las columnas, necesitaría convertir las fechas que está usando como parámetros como cadenas en el formato apropiado y luego confiar en el hecho de que la clasificación de cadenas en ese formato particular coincide con el orden de clasificación esperado de las fechas reales. Si alguna vez compara la cadena con la fecha o con un número, obtendrá una conversión de tipo de datos implícita que, en el mejor de los casos, provocará problemas de rendimiento porque no se pueden usar los índices y, en el peor de los casos, generará resultados incorrectos o errores.
Suponiendo que evita la conversión de tipos de datos, es probable que los problemas de rendimiento surjan del hecho de que el optimizador tiene muchas dificultades para estimar la cardinalidad cuando utiliza el tipo de datos incorrecto. Oracle sabe, por ejemplo, que hay 365 días (o 8760 horas o 525600 minutos) entre el 1/1/2012 y el 1/1/2013. Por otro lado, hay miles de millones de cadenas posibles entre '20120101000000' y '20130101000000'. Eso puede hacer que el optimizador no use un índice cuando le gustaría (o viceversa), que use el tipo de combinación incorrecto, etc.
