INDEX une date ou PRIMARY INDEX un datetime ? [MySQL] - Programmation
Marsh Posté le 09-02-2002 à 17:50:51
Si tu as un 2eme champs qui pris avec la date peut faire une primary key, c'est ce qu'il faut faire, sinon, datetime.
Mais avant tout, il faut se poser la question de savoir si tu as vraiement besoin d'une priamry key ?
Marsh Posté le 09-02-2002 à 18:37:52
Non je n'ai pas spécialement besoin de Primary Key. Ce que je veux savoir c'est si c'est plus rapide quand on fait une recherche avec WHERE. Et si c'est le cas ma question est de savoir si pour la vitesse il vaut mieux un Primary Key avec une données plus grande ou un Index avec une données plus petite.
PS : c'est Primary Key que je voulais écrire dans mon premier post et pas Primary Index (erreur !)
Marsh Posté le 09-02-2002 à 20:25:45
Tout dépend de ce que tu veux faire.
Si tu te contente de la partie Date dans le where, un index simple sur date est ce qu'il te faut.
Une primary key est un index comme les autres, il est pas plus rapide.
Marsh Posté le 09-02-2002 à 22:42:22
OK donc je prend la solution 1 car en fait je n'ai pas besoin de l'heure. Je voulais juste savoir si avec des index uniques c'était plus rapide qu'avec des index normaux.
Marsh Posté le 09-02-2002 à 17:01:57
Deux possiblités :
1. Indexer un champs date
2. Primary Index un champs datetime
Le champs est à chaque fois renseigné par la date du jour dans les deux cas + l'heure dans le 2e.
Donc en fait je n'ai pas besoin de l'heure, c'est pour ça qu'en 1 y'a que date. Mais comme il peut y avoir pls enregistrements dans la même journée le 1 ne peut pas être Primary (Primary = Unique). Pour le 2 il est quasi-impossible que j'ai un champs renseigné dans la même seconde donc pas de pb pour l'unicité de l'enregistrement.
Alors que faire :
1. Privilégier la taille (3 octects) au prix de l'unicité de l'index
2. Privélégier l'unicité de l'index au prix de la taille (8 octets)
Je répète que je n'ai pas besoin de l'heure et que c'est juste au niveau des perfs que ça m'intéresse.
Merci d'avance.