MagicBuzz a écrit :
Une date (du moins dans SQL Server, mais pour Oracle, ça doit être à peut près la même chose) est stockée dans un float.
La partie entière contient le nombre de jours écoulés depuis le 01/01/1900 (ou un truc du genre), et la partie décimale contient le nombre de milli-secondes écoulées depuis le début de la journée indiquée dans la partie entière. Sous Unix (Oracle repose peut-être plutôt là dessus) c'est stocké dans un double, et c'est le nombre de milli-secondes depuis le 01/01/1900 (ou je ne sais plus quelle date, je sais jamais )
Donc, pour faire une comparaison entre un deux dates, il s'agit d'une comparaison de float ou de double, ce qui est en effet bien plus rapide qu'une comparaison de chaîne.
Deplus, pour faire une comparaison de date à partir d'une chaîne, il faut faire attention au format de la date... En effet, "01/12/2003" < "05/01/2003", alors qu'au niveau date (au format international) c'est faut. Le format anglais quand à lui commence à merde quand l'année change.
Il faut donc se baser sur le format ISO, qui est de la forme "YYYYMMDD HH:MM:SS MS"
A ce moment, la comaraison sera bonne.
Pour en revenir au niveau des performances, truc simple :
-> Niveau performances pures théoriques, la comparaison entre deux dates de type date est énormément plus rapide.
MAIS, tu remarqueras que dès que tu as une date dans une requête, to fait très souvent des TO_CHAR() et des TO_DATE() à n'en plus finir. Ceci est "très" consommateur, surtout si c'est sur un des champs scannés que tu fais ce traîtement (il faut mieu adapter les champs minoritaires en nombre au format des champs majoritaires en nombre que l'inverse, donc ne jamais faire :
where TO_CHAR(champDate, 'YYYYMMDD') > '20030101'
mais plutôt :
where champDate > TO_DATE('20030101', 'YYYYMMDD')
Mais c'est pas toujours évident de s'en sortir comme ça, et pour des raisons de compatibilité (connection ODBC, interrogation de la base avec un client dans une langue différente) il vaut généralement mieu stocker la date ISO au format char(8).
En effet, outre le faire qu'on a plus besoin de faire 50 conversions dans tous les sens, il y a un autre gain notable : si on index les champs date, alors niveau SGBD, ils sont vus comme un arbre, basé sur des entiers. Le gain est donc énorme. Par contre, di tu stockes au format natif date, le passage à un arbre de nombres sera moindre, puisque c'est déjà des nombres (tu ne gagnes que le gain dû à l'arborescence - ce qui est déjà pas mal). Anyway : Au final, si tu index le champ, les perfs seront "rigoureusement" les mêmes entre un champ de type char ou un champ de type date. Il y a une différence minime, mais qui est suffisament réduite pour être ignorée.
|