Ce serait bien mieux si les dates étaient stockées sous forme de dates. Les stocker sous forme de nombres plutôt que de chaînes introduit un autre ensemble de problèmes.
Si vous êtes absolument coincé avec des dates stockées sous forme de chaînes, afin de permettre l'utilisation d'index sur les colonnes, vous devez convertir les dates que vous utilisez comme paramètres sous forme de chaînes dans le format approprié, puis compter sur le fait que le tri des chaînes dans ce format particulier correspond à l'ordre de tri attendu des dates réelles. Si jamais vous comparez la chaîne à une date ou à un nombre, vous obtiendrez une conversion implicite du type de données qui, au mieux, entraînera des problèmes de performances car les index ne peuvent pas être utilisés et, au pire, générera des résultats incorrects ou des erreurs.
En supposant que vous évitiez la conversion des types de données, les problèmes de performances sont susceptibles de provenir du fait que l'optimiseur a beaucoup de difficulté à estimer la cardinalité lorsque vous utilisez le mauvais type de données. Oracle sait, par exemple, qu'il y a 365 jours (ou 8760 heures ou 525600 minutes) entre le 01/01/2012 et le 01/01/2013. D'autre part, il existe des milliards de chaînes possibles entre '20120101000000' et '20130101000000'. Cela peut amener l'optimiseur à ne pas utiliser un index lorsque vous le souhaitez (ou vice versa), à utiliser le mauvais type de jointure, etc.
