optimiser une requete PHP/MySQL

[vsmetal]

Voila, g une table "fetes" qui comprend tous les saint avec leur jour correspondants (un champ id, un champ mois, un champ jour, un champ fetes) avec ID comme clé primaire. Pour l'instant, la ligne SQL permettant d'afficher le saint du jour est :

<?
$tt=time();
$mois=date("m",$tt);
$jour=date("d",$tt);
$result = @mysql_query("select FETE from fetes where MOIS=$mois And JOUR=$jour");
$fete=mysql_result($result,"FETE");
echo $fete;
?>

Je trouve que c un peu lent, yaurait-il moyen d'optimiser cette requête ?

 

[joce]

ALTER TABLE fetes ADD UNIQUE (MOIS,JOUR);

 

[vsmetal]

lut Joce
j'ai juste à éxécuter cette commande ? sans rien changer à ma base ?

 

[joce]

yep, ca va rajouter l'index qui va bien pour avoir des perfs plus que correctes

 

[JWhy]

j'ai une question: vaut-il mieux garder le champ ID et mettre MOIS et JOUR en UNIQUE (comme le conseille Joce) ou bien faire sauter l'ID et mettre MOIS et JOUR en clés primaires ? :??:

 

[joce]

[citation=368,1][nom]JWhy a écrit[/nom]j'ai une question: vaut-il mieux garder le champ ID et mettre MOIS et JOUR en UNIQUE (comme le conseille Joce) ou bien faire sauter l'ID et mettre MOIS et JOUR en clés primaires ? :??:
[/citation]à priori que ce soit clé primaires ou unique c'est kifkif, par contre ID est peut être inutile ici effectivement

 

[MagicBuzz]

Joce > Ton truc ne marche que si JOUR,MOIS est réellement unique.

A ce moment, ID est inutile d'ailleurs.

Mais si dans cette table VsMetal veut stocker les jours fériers de plusieurs pays, le couple JOUR,MOIS risque fortement de ne plus être unique.

Il vaut mieu dans ce cas créer simplement un index sur ce couple (plus un champ pays qui sera mambre du couple et qui permet de retrouver les jours feriers d'un pays particulier)

 

[cisco]

bien vu, si il y a plusieurs fetes le même jour, on pourra pas les rentrer!

 

[JWhy]

vu son code actuel, meme si la base permet d'avoir plusieurs FETES par JOUR/PAYS, VsMetal ne pourra pas en faire grand chose

 

[MagicBuzz]

ouais c clair, m'enfin avoir pondu un ID pour cette table montre une base un peu bancale

 

[vsmetal]

bon, ok, l'id, c t pas une franche id (justement ), ms sinon, ça marche nickel.
-> pour couper court à tte supposition : y'a que les fêtes de notre chère France qui sont dedans

A part ça, pkoi vous dites que je pourrais pas en faire gd chose ?

 

[JWhy]

meme si tu autorisais dans ta base plusieurs JOUR/MOIS identiques, ton code actuel ne récupere que le premier résultat

 

[cisco]

les clef primaires de tables ne doivent pas être des éléments 'business' (comme MOIS/JOUR). Donc je garderai l'ID comme clef primaire. (mais ca n'empeche pas d'ajouter des contraintes)
Mais ca n'empeche pas de rajouter un index sur MOIS/JOUR pour optimiser la base

 

[vsmetal]

ma base est terminée et ne contient pas plusieurs jour/mois identiques , sinon, j'aurais fait un array pour le result

 

[joce]

[citation=379,1][nom]cisco a écrit[/nom]les clef primaires de tables ne doivent pas être des éléments 'business' (comme MOIS/JOUR). Donc je garderai l'ID comme clef primaire. (mais ca n'empeche pas d'ajouter des contraintes)
Mais ca n'empeche pas de rajouter un index sur MOIS/JOUR pour optimiser la base
[/citation]ba pour mysql à priori une primary key et un index UNIQUE c'est kifkif, alors autant économiser des indexs, surtout qu'il veut pas faire de jointure

 

[cisco]

ba pour mysql à priori une primary key et un index UNIQUE c'est kifkif, alors autant économiser des indexs, surtout qu'il veut pas faire de jointure

c'était plus pour dire que un truc qu'on croit unique dans le temps (style ici couple MOIS/JOUR) peut plus tard s'averer non unique (style ici plusieurs fetes le même jour)
Ca peut conduire a des catastrophe si le couple MOIS/JOUR est suposé etre une clef unique dans l'application. (J'ai eu un cas catastrophe chez un opérateur telecom...)
Donc une regle de prudence est de considérer les données business fixes comme contraintes, mais de pas les utiliser comme clef primaire dans l'application
(mais d'en tenir compte lors de la normalisation de la base)

Enfin moi je dis ca, je dis rien

 

[joce]

[citation=434,1][nom]cisco a écrit[/nom]

ba pour mysql à priori une primary key et un index UNIQUE c'est kifkif, alors autant économiser des indexs, surtout qu'il veut pas faire de jointure

c'était plus pour dire que un truc qu'on croit unique dans le temps (style ici couple MOIS/JOUR) peut plus tard s'averer non unique (style ici plusieurs fetes le même jour)
Ca peut conduire a des catastrophe si le couple MOIS/JOUR est suposé etre une clef unique dans l'application. (J'ai eu un cas catastrophe chez un opérateur telecom...)
Donc une regle de prudence est de considérer les données business fixes comme contraintes, mais de pas les utiliser comme clef primaire dans l'application
(mais d'en tenir compte lors de la normalisation de la base)

Enfin moi je dis ca, je dis rien
[/citation]
ba au pire si tu veux changer tu droppes l'index