Discussion :

[.mok.]

Salut,

J'ai lu pas mal de choses sur les index, et notamment qu'ils sont interessants lorsque l'on tourne avec beaucoup de SELECT.

Je ne fais qu'un insert par mois, le reste du temps uniquement du select.

Ma table est conçue comme ceci :

date, utilisateur, eau1, eau2, eau3, gaz1, gaz2, gaz3, ele1, ele2, ele3

J'ai lu qu'on pouvait mettre des index sur chaque colonne ou sur un groupe de colonnes. Dans mon cas les select sont souvent réalisés en fonction d'une date, et d'un type (eau, gaz, ele).

Je ne vois pas trop comment les disposer...

Si quelqu'un pouvait m'éclairer

Merci d'avance

[Antoun]

Qu'y a-t-il dans tes colonnes eau1, gaz2, etc. ?
Combien de lignes as-tu ?

[.mok.]

Désolé pour l'imprécision.

Pour la date, c'est un timestamp et l'utilisateur un varchar; les colonnes eau et elec sont en medium int et les colonnes gaz en décimal.

J'ai à peu près 120 lignes dans la table

[Antoun]

Avec 120 lignes, je pense qu'il est totalement inutile de se casser la tête avec des index !

[.mok.]

J'imagine bien qu'avec 120 lignes, l'influence des index est moindre. Mais la table est biensûr amenée à grossir. A partir de combien de ligne les index peuvent ils avoir une incidence positive sur les performances ?

[Antoun]

Disons quelques milliers. 120 lignes, c'est considéré comme microscopique pour un SGBD.

[Eric93]

En SQL tout est possible comme requête, mais si la table est grosse, ca peux devenir long.

D'une facon générale, pour les grosse requête tu positionne des index qui correspondent aux colonnes de la clause WHERE, ce qui évite de parcourir toute la table.

Mais c'est vrai que dans ton cas c'est inutile