10-03-2011, 03:10 PM
Ça dépends de la manière dont tu veux traiter tes données.
D'abord, créer un index sur l'année dans ce cas me semble peu judicieux.
Ça va prendre de l'espace disque pour au final une efficacité plus que minime car d'ici quelques années, ton index ne contiendra qu'une poignée de valeurs différentes pour des milliers d'enregistrements.
Même question sur le mois. A quoi servira un index qui au final ne contiendra que 12 valeurs différentes ?
La plupart des moteurs SQL avec un peu de jugeote préfèreront partir sur un table scan pour éviter les lookups incessants entre la table d'index et les données.
Autant indexer sur un format ODBC canonique (YYYY-MM-DD) qui permet bien plus de facilité pour une recherche encadrée (log_date BETWEEN '2011-03-01' AND '2011-03-31').
D'abord, créer un index sur l'année dans ce cas me semble peu judicieux.
Ça va prendre de l'espace disque pour au final une efficacité plus que minime car d'ici quelques années, ton index ne contiendra qu'une poignée de valeurs différentes pour des milliers d'enregistrements.
Même question sur le mois. A quoi servira un index qui au final ne contiendra que 12 valeurs différentes ?
La plupart des moteurs SQL avec un peu de jugeote préfèreront partir sur un table scan pour éviter les lookups incessants entre la table d'index et les données.
Autant indexer sur un format ODBC canonique (YYYY-MM-DD) qui permet bien plus de facilité pour une recherche encadrée (log_date BETWEEN '2011-03-01' AND '2011-03-31').
Quand on te dit qu'un projet est terminé à 90%, prépare toi pour les 90% suivant
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC