Où placer les index dans une table de dimension temporelle?

Après avoir lu les questions et réponses de ce site Web sur les index, une question m'est venue à l'esprit.

Et si, on utilise une table de dimension temporelle avec le niveau de granularité inférieur étant le jour. Où placer les index?

Randy Melder dans la question: Que signifie «index» sur RDBMS? m'a dit :

Considérez un index comme une "table des matières" ... c'est-à-dire une liste ordonnée de pointeurs vers des positions dans un fichier, alias décalages

Dans le cas de la dimension temporelle, la plupart des recherches de données peuvent être effectuées soit pour un jour spécifique, une semaine spécifique, un mois spécifique ou un trimestre spécifique si le calendrier stocke toute la journée pour une année unique .

Ma question est: faut-il mettre des index pour tous ces champs?

Le jour est censé être unique, donc pour celui-ci, je comprends parfaitement l'utilisation des index. Mais un identifiant de semaine aura 7 occurrences , un identifiant de mois aura 30/31 occurrences , un identifiant de quart aura plus ou moins 120 occurrences .

• Faut-il encore mettre des index pour ces champs?
• Sera-t-il toujours utile?

Je vous le demande parce que dans la même question, David Spillett a dit:

Ajouter trop d'index peut être une mauvaise optimisation, bien sûr, car l'espace supplémentaire utilisé pour stocker les index (et la charge d'E / S pour les maintenir si votre base de données voit de nombreuses opérations d'écriture) peut être un problème pire que les requêtes de lecture légèrement moins optimales , alors ne le faites pas trop.

Quelles seraient donc les meilleures considérations pour le cas de la dimension temporelle?

Vous ne rencontrerez probablement pas les problèmes de problèmes d'écriture, car je suppose que ce serait quelque chose de créé une fois (ou une fois par an), puis non touché.

Mais l'utilisation d'un index sera probablement un obstacle si vous effectuez une recherche par semaine ... Le problème est que si l'index est utilisé, il peut le scanner en premier, puis récupérer chaque enregistrement de la table individuellement, ce qui lorsque vous '' Pour extraire plus de 5 à 20% des enregistrements, il est généralement plus rapide d'effectuer une analyse complète de la table, puis de supprimer les enregistrements qui ne vous intéressent pas.

Je ne connais aucun SGBDR majeur qui n'optimise pas pour cela quand ce sont des données bien distribuées. Si elle n'est pas bien distribuée (par exemple, l'une des valeurs d'une colonne se produit 95% du temps, mais il existe également d'autres valeurs possibles), vous devrez peut-être calculer des histogrammes sur la table et ne pas utiliser d'espace réservé pour la valeur lors de la recherche, afin que l'optimiseur de requête ait la valeur recherchée lors de la génération du plan d'exécution.

Je n'indiquerais probablement pas le jour de la semaine. Je vérifierais la documentation de ma base de données pour voir quel est leur compromis entre les lectures indexées et les analyses de table complètes pour voir si j'indexerais le jour du mois ou du mois de l'année. J'indexerais probablement DOY / jour de l'année s'il est présent (ce qui semble être votre index unique, de toute façon)

Un index n'a pas besoin d'être unique pour être utile, donc la réponse est que cela dépend . Si vos requêtes bénéficient de la présence de l'index, elles peuvent être un ajout intéressant. Je ne sais pas s'il devrait y avoir des directives spéciales concernant les colonnes de temps. Traitez-les comme toutes les autres colonnes et indexez-les en fonction de l'utilité des requêtes.

La règle générale est que plus l'index est sélectif (la sélectivité étant définie comme le nombre de valeurs uniques dans une colonne divisé par le nombre de lignes de la table), plus il est probable que le moteur utilise l'index si une requête utilise la colonne dans une clause where.

Si vous envisagez d'indexer une colonne, exécuter une requête en sélectionnant la colonne indexée avant et après et en consultant les plans d'exécution vous dira si l'index est utilisé et, dans l'affirmative, dans quelle mesure l'index aide. Idéalement, la requête que vous utilisez pour le test est celle qui serait utilisée par votre application.

Jusqu'à présent, ma règle d'or a été de ne pas mettre d'index dans mes bases de données de développement pendant que je travaille dessus. À mesure que la base de données de production s'agrandit, j'utilise la journalisation de la base de données et EXPLAINpour déterminer ce qui doit être indexé, puis je crée uniquement les index nécessaires. Cela fonctionne bien tant que l'utilisation de la base de données augmente progressivement et maintient le nombre d'index bas.

Lors de l'analyse des données dans la base de données, j'ai généralement besoin d'ajouter des index supplémentaires pour accélérer les demandes qui ne sont pas courantes en production. Je le fais toujours sur des copies de la base de données de production, de sorte que ces index ne sont jamais ajoutés à la production eux-mêmes.