Redondance calculée : bénéfique ? [Résolu]

[JackBeauregard]

Bonjour,

Une question très simple dont la réponse me parait à moi même évidente, mais bon vous saurez peut-être me dire des choses intéressantes sur le sujet.

Laquelle des deux requêtes est la plus rapide ?

Code :

1
2
3
 
$totalRep=
"SELECT count(id) AS id  FROM forumReponse WHERE idCom='".$forumDiscussion."'

ou

Code :

1
2
3
 
$totalRep=
"SELECT nbrId FROM forumSujet WHERE id='".$forumDiscussion."'

La deux me direz-vous... Mais dans quelle proportion ?

[Eusebius]

Qu'est-ce qu'il y a exactement dans le champ nbrId pour que les deux requêtes soient comparables ? la somme déjà faite, reproduite dans tous les enregistrements ? j'espère pas...

pour la rapidité je ne sais pas, mais pour les ressources utilisées, je dirais que la première est plus soft, elle ne renvoie pas quarante mille résultats.

[KiLVaiDeN]

Euh salut,

Je pige que dalle à ta deuxième requête, et je ne vois pas en quoi elle est équivalente à la première, mis à part si la colonne "nbrId" de ta table forumReponse contient le nombre d'enregs pour le $forumDiscussion en cours, ce qui serait redondant et totalement bizarre

Sinon, en prenant cela comme hypothèse, je dirais que la deuxième méthode est bien entendu plus performante, si l'information est constamment mise à jour, c'est un simple accès, alors que l'autre implique un "calcul".

Tu peux encore accélerer en ne prenant que le premier élément, avec tes paramètres de selection ( par exemple sous Oracle je crois qu'un WHERE rownum < 2 suffit )

Je pense que certains SGBD optimisent ce genre de calculs ( SUM, AVG, COUNT, comme dans ta méthode numéro 1 ) cependant je ne saurais me pencher la dessus sans bille, et je ne ferais pas de commentaire sur quelque chose que j'ignore !

[JackBeauregard]

Bon en fait quand j'enregistre une nouvelle réponse à un sujet, j'incrémente de 1 le nombre de réponse de la table des sujets.
Donc j'ai déjà le nombre total de réponse disponible et je pense qu'il vaut mieux aller le repiquer avec la seconde requête plutot que de faire un count() à chaque fois comme avec la première requête.
Qu'est-ce que vous en pensez ?

[berceker united]

Dans ce cas je dirais la deuxième puisqu'il y a aucun calcule a faire, il n'a pas à parcourir la table pour compter le nombre d'enregistrements.

[JackBeauregard]

C'est sûr.
C'est sans doute la question la plus intéressante que j'ai posté.

()

[KiLVaiDeN]

Envoyé par JackBeauregard

C'est sûr.
C'est sans doute la question la plus intéressante que j'ai posté.

Ceci dit, c'est en effet interessant; les indexs mis sur une colonne permettent peut-être d'avoir ce genre d'information BEAUCOUP plus rapidement qu'on ne le croit, et donc si ça se trouve, sous certaines conditions, il peut être plus rapide de faire un COUNT ( accès à l'index, et récupération d'une valeur dans celui-ci ) plutot qu'un accès direct à une table non indéxée, mais je l'ai dit, il ne faut pas que je m'aventure à m'avancer sur des affirmations qui tiennent de l'ordre du suppositoire... Euh, ou plutot de la supposition

A+

[JackBeauregard]

Bon alors j'enlève délestage, si d'autres veulent rebondir.

[Biglo]

Eh oui justement, moi je dirais la première !

S'il y a un index sur idCom, MySQL est capable de savoir très rapidement combien de lignes vont être retournées. Il n'a même pas besoin d'analyser les données, il suffit d'analyser l'arbre des index. Alors que la deuxième nécessite d'analyser les index + les données de la table pour récupérer la colonne du SELECT.

[JackBeauregard]

Oui y'a un index sur idCom. Mais par contre j'ai modifié tous mes scripts. Alors pour que je remodifie tout, il va falloir me convaincre...

[Biglo]

Ne compte pas sur moi pour te convaincre, je n'ai pas envie de te donner du travail supplémentaire

Ceci dit, j'ai fait un test : les deux tables (très simplifiées), 50 000 sujets avec entre 0 et 50 réponses par sujet. On obtient un résultat très proche pour les deux requêtes, mais j'ai quand même noté un petit avantage de 0,1 ms (peut-être moins, MySQL Query Browser ne va pas jusqu'aux micro secondes ... il arrondit ) pour la deuxième requête.

Mais ça ne veut pas dire que la deuxième sera dans tous les cas plus rapide que la première. Comme je l'ai dit, les tables sont très simplifiées pour mon test. Plus il y aura de colonnes, plus la deuxième requête mettra du temps (l'accès disque sera plus long). Par contre, la première n'est pas gênée par la taille d'un enregistrement car l'index suffit pour déterminer le COUNT.

Comment expliquer que la deuxième l'emporte lors de mon petit test ? (En d'autres termes, comment expliquer que je me sois trompé ).

Eh bien, je dirais qu'il est beaucoup plus rapide de rechercher une valeur à indexage unique (ici PRIMARY KEY) que de chercher une valeur à indexage "simple" (ici FOREIGN KEY). Rechercher un idCom=xxx pour la table ForumReponse était dans mes tests plus long que rechercher id=xxx + lire le champ nbrId pour la table ForumSujet.

Mais personnellement, je choisirais quand même la première requête. Car je suppose qu'à chaque réponse postée, tu incrémentes nbrId du sujet concerné. Et au final, même si la deuxième requête te permet de gagner 0,1ms, tu en perds sûrement beaucoup plus avec un UPDATE (lecture + écriture disque).

[JackBeauregard]

Intéressant
Pour la prise en compte de l'index par mysql, ne faut-il pas s'en référer aussi à la version de celui-ci ? Moi je travaille sur mysql 4.0.25 par exemple.