Soyez le premier à donner votre avis sur cette source.
Snippet vu 9 035 fois - Téléchargée 19 fois
//Chaine de connexion à la Bdd ici include("connect.php"); // On recherche le MAX $result=mysql_query("SELECT max(id) FROM matable WHERE cid='6' AND uid='1' ORDER by id ASC") or die(mysql_error()); $MAX= @mysql_result($result, 0); echo "Nb Val. ( val MAX) : $MAX (prochain serait $MAX + 1 )<br>"; echo "<hr>"; // On regarde les valeurs qui existent dans la table $requetesub=mysql_query("SELECT id FROM matable WHERE cid='6' AND uid='1' ORDER by id ASC") or die(mysql_error()); $totalsub = mysql_num_rows($requetesub); // Pour info/test on affiche des résultats echo "$totalsub ID relemnt occupé ( "; while ($row = mysql_fetch_array($requetesub, MYSQL_ASSOC)) { echo " {$row['id']} "; } echo")<hr>"; //On remet le pointeur au début. afin de parcourir de nouveau le tableau mysql_data_seek($requetesub, 0); $i=-1; //(-1 pour tester la valeur 0) $p=0; //sera le pointeur. while($i<$MAX) { $i++; echo "<br> <u><b>Test de la valeur</u> : {$i} </b><br>"; $row = mysql_fetch_array($requetesub, MYSQL_ASSOC); $val = $row['id']; if($val==$i) { echo"La valeur est = à i -> la preuve :($val=$i)"; //on bouge le pointeur d'1 point $p++; @mysql_data_seek($requetesub, $p); // A ce niveau, à la dern. valeur on aura une erreur de dépassement. // Il faut donc prévoir un petit changement ou un test sup. // Le @ évite simplement l'affichage du message d'erreur. } else { echo"ID libre trouvé : <b>$i</b> ($val=$i)"; //on ne déplace pas le pointeur mysql_data_seek($requetesub, $p); // ---- ICI on ferai un RETURN de l'ID si on fais une fonction ---- } echo"<hr>"; }
19 sept. 2007 à 23:07
Je rajouterai, au fait que ça n'a aucun intêret de boucher les trous dans les id, que cela ne peut amener que des problèmes surtout s'il y a plusieurs utilisateurs qui saisissent des données en même temps :
le même id (max id+1) peut etre attribué plusieurs fois à des utilisateurs différents, tant qu'il n'aurra pas été enregistré dans la bd, et donc lors de l'enregistrement pour les utilisateurs suivants, des doublons ou des blocages à l'insert peuvent apparaître suivant la nature de la cle concernée (unique ou pas)...
Quand à moi je préfère laisser mysql gérer ça tous seul...c'est son job...
... peu-etre penser aussi à last_insert()
bonne continuation
14 sept. 2007 à 14:08
Je vais également ajouté des LIMIT à mes requêtes....
14 sept. 2007 à 14:02
Pour les benchmarks, pourquoi ne pas faire la somme du temps d'exécution de 100 000 instructions ? On y verrait plus clair. Le nombre ROWS de EXPLAIN n'est pas significatif, ça ne veut pas dire que MySQL va parcourir plus de lignes pour un > + LIMIT. C'est uniquement le nombre de résultats possibles, point.
Ta conclusion qui est de dire qu'ordonner une table selon l'ordre où les lignes sont les plus sollicitées me paraît tout à fait logique. Ca revient à faire ORDER une seule fois et pas à chaque SELECT. Sauf que j'en reviens au problème de base :
1) ce n'est pas le métier de la clé primaire de servir pour l'ordre. D'ailleurs une nouvelle ligne vient prendre un id libre au pif, en tout cas dans cette source.
2) sous MyIsam, la clé primaire ne définit PAS l'ordre des lignes dans la table. Une nouvelle ligne ne sera pas accédée plus vite qu'elle porte l'id 3 ou l'id 265972545.
Donc fondamentalement, boucher les trous des ID ne sert à rien et causent des pbs. Ensuite si tu veux réordonner ta table à chaque insertion, libre à toi, ça peut être un choix judicieux dans certains cas précis, mais il n'y a pas de rapport avec le fait de boucher les id libres.
Je signale quand même qu'avec ta technique Coucou, je pense que tu ne peux pas utiliser de clé index, puisqu'au moment de la recherche ça viendrait à l'encontre de la façon dont tu as réordonné ta table par toi-même. Ce qui est coûteux pour toutes les requêtes autres que ta (ton unique) requête optimisée. A moins qu'il soit possible de spécifier quand on fait un SELECT de tenir compte ou pas des colonnes indexées ? Mais je n'en ai jamais entendu parler.
SuperTonic : tout simplement, si tu fais SELECT name where id 5; MySQL va trouver la ligne, puis continuer pour voir s'il n'y en a pas d'autre ou id 5. Ce qui est idiot parce que tu sais que chaque id et unique, donc il nen trouvera rien. Avec LIMIT tu lui dit d'arrêter de chercher.
Tu peux aller lire la doc officielle de MySQL, il y a un chapitre entier sur l'optimisation.
14 sept. 2007 à 12:02
http://blogs.codes-sources.com/coucou747/archive/2007/09/14/bench-sur-la-pagination-sous-mysql.aspx
mais meme ton WHERE + limit, ca revient a faire :
WHERE champ_dans_l_ordre >= page*nbr_par_page LIMIT nbr_par_page
donc ton champ doit-etre dans l'ordre...
le explain semble indiquer que... les benchs sont toutefois plus reserves...
14 sept. 2007 à 11:58
@SuperTonic : Si tu indiques correctement les conditions, oui. C'est important (mais pas indispensable) car il permet de ne pas mobiliser plus de ressources que nécessaire. C'est de l'optimisation. Pourquoi charger en mémoire tous les enregistrements quand tu n'as besoin que des 10 premiers, ou que du 11ème au 20ème (par exemple...) ?
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.