Discussion :

[Michel Rotta]

Je dois créer une table qui va comprendre, entre autres, deux champs qui vont correspondre à une heure de départ et une heure de fin. Ces deux heures sont exprimé en quart d'heure (impossible d'indiquer des unités de temps inférieure au quart d'heure.

Ces données seront stockée dans des champs entier long, le premier quart d'heure (0) sera celui du 2000/01/01 00:00 celui de l'heure de rédaction de ce présent message (2011/02/10 14:45) sera le 16.291.

Je veux retrouver tous les enregistrements qui passent par une fenêtre de temps données qu'il commencent avant et/ou finissent après et/ou pendant...

La requête sera dans le genre :
heure_depart_enregistrement < heure_fin_fenetre et heure_fin_enregistrement > heure_depart_fenetre

La structure applicative s'assure que l'on ait toujours :
heure_fin_enregistrement > heure_depart_enregistrement

Ce type de requête va être au cœur de l'application et sera très courante. Il convient donc de l'optimiser au maximum par un index.

Quel est l'index idéal pour optimiser ce type de requête ?

J'avais pensé à :
heure_depart_enregistrement ASC, heure_fin_enregistrement ASC.

Y a-t-il mieux à faire ?

D'avance merci

[CinePhil]

À condition que tes heure_depart_fenetre et heure_fin_fenetre soient exprimés dans la même unité pour ne pas opérer de calcul de conversion en SQL, ce qui empêcherait l'utilisation de l'index, ton idée me semble bonne.

[Michel Rotta]

Les deux champs sont des entiers longs exprimé en quart d'heure commandant au 1 janvier 2000. Je me limite a 12500 années, ce qui devrait dépasser la durée de vie de l'application !

Bon, je me lance. Dans le pire des cas, un index, ça peux ce modifier en cours de route.

Merci

[CinePhil]

Si tu as déjà un paquet de données, fais un EXPLAIN de la requête pour voir s'il utilise bien ton index.

Tu peux aussi tester avec deux index mono-colonne puis avec l'index double-colonnes pour voir lequel est le plus rapide. Normalement, ça devrait être le double-colonnes.

[Michel Rotta]

Sauf erreur de ma part, MySql n'utilise qu'un index par requête ?

Je n'ai pas (encore) beaucoup de donnée, la table n'est même pas créée. Et le programme pour la remplir n'existe même pas dans mon esprit mais je tenterais le coup, j'y accède par Doctrine 2 et Symfony, mais je peux récupérer le SQL, donc faire un EXPLAIN

Et je pense, à la réflexion, que je vais devoir faire plusieurs index multiple, vu que l'on peut accéder aux informations par personne (une personne à une collection d'horaire) ou par site et/ou par bâtiment (une personne travail sur un site dans un bâtiment) et il faut pouvoir récupérer les horaires pour tous ces gens (je peux skiper le site en considérant que la personne travaille obligatoirement dans un bâtiment, donc faire la requête pour tous les bâtiments (in) du site). D'où trois index à maintenir un général, un par personne, un par bâtiment.