Il est étonnant que cette optimisation ne soit pas effectuée par le SGBD. Peut on avoir une liste fiable des SGBD pour lesquels il faut effectivement faire le travail à leur place ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Il est étonnant que cette optimisation ne soit pas effectuée par le SGBD. Peut on avoir une liste fiable des SGBD pour lesquels il faut effectivement faire le travail à leur place ?
Je dirais toute celle qui utilise un équivalent au LIMIT. Mais !...Envoyé par Blustuff
En fait, il est rare de faire une pagination sur des centaines de milliers d'enregistrements mais pour 10 000 enregistrements je ne pense pas qu'il y ait de problème.
La structure d'une base de données peut changer selon la quantité d'information qu'il doit gérer.
Pour le LIMIT il est un peut normal que ça mette beaucoup de temps pour une telle quantité donc il faut passer par une autre technique telle que je site mais il faut pas l'utiliser systématique pour un faible volume.
Si l'optimisation peut être systématique, alors les SGBD la feraient systématiquement, vu qu'elle n'est pas excessivement compliquée. Quel est le détail qui fait qu'ils ne font pas ce travail ?
Test de performance entre les deux methodes avec de fort volume.
Vous ne donnez pas de raison pour laquelle votre méthode serait moins performante.
Laquelle qui serait moin importante ? Utiliser un LIMIT ou le BETWEEN.
Si c'est le LIMIT. Les performances tombent lorsqu'il y a énormement d'enregistrement sur la les tables joints. Par exemple, sur un forum ou le nombre de page d'un topic est complétement aléatoire. Sur le site hardware.fr il y a des topic ou il y a un topic sur Sarkozy qui lui possède 2993 pages à l'heure ou j'écris. en sachant qu'il y a 30 interventions par page donc 2993x30 = 89790 enregistrements. La consultation des données vers la page 1,2,3,4,... vont être rapide mais vers la fin ça va être plus long. Le moteur doit parcourir toute la ou les tables join quasiment enregistrement par enregistrement. Ceci jusqu'a qu'il arrive au bon curseur (numéro de page) et de la il retourne les x élément par la suite. Dans l'exemple c'est 30. Ce qu'il bouffe aussi c'est qu'il est obligé de ranger les données par date. Le ORDER BY + LIMIT en même temps greffe les perfs.
Non, l'autre méthode.
Si c'est le BETWEEN, non je concidère pas que c'est une méthode moin performant, bien au contraire.
Peut être que c'est moi qui m'y suis mal expliqué ou une coquille.
Mais alors pourquoi cette optimisation n'est pas faite systématiquement par les SGBD ?
Dans un SGBD qui autorise les requêtes imbriquées, on pourra écrire ça encore plus concisément. Une règle qui est assez souvent appliquée est de laisser le SGBD optimiser la requête et de ne pas faire ce genre de choses. Bien sûr, il peut y avoir des exceptions, mais il faut être bien certain de ce que l'on fait, d'où ma question.
Oui biensure, ce que je donne peut se faire naturellement dans une requête imbriqué c'est même mieux.
Pourquoi ce n'est pas optimisé ? Personnellement, je ne lui reproche pas que ça soit pas optimisé parce que cela nécessite de prendre beaucoup de paramètre en compte. La taille éventuelle qui sera retourné, le nombre de table impliqué dans la requête. De plus, pour en arriver à avoir plus de 2000 pages ... Cela en vaut-il la peine de faire une exception. Par rapport au bench et au developpeur traitant de ce problème c'était la meilleur solution. Le forum Hardware.fr malgré qu'il soit sur SQL Server utilise la même technique pour les mêmes raisons.
Tu es sûr ? Moi si j'étais un SGBD et que je devais retourner les 30 résultats à partir de la page 1985, ben je me contenterai de déplacer un pointeur jusque cette zone mémoire et de retourner ce qu'il faut. Après reste à voir le fonctionnement interne de la SGBD, je suis sur que ce sont des programmes bienb bourrins ^^
C'est simple PhpBb utilise le LIMITc'est pour cela qu'arriver à un certain nombre de page ce forum devient un veau et que beaucoup d'hebergeur ne veulent à avoir ce forum chez eux
.
Merci pour les infos,
je viens de regarder le code source de vbulletin et effectivement ils chargent les messages via un IN () en prenant leurs ID.
J'ai regardé le code source de phpBB3 et ils ont corrigés ce problème aussi, donc phpBB3 ne souffrira pas de ce défaut.
Me reste plus qu'à modifier la source de mon forum
PhpBb3 est apparement un très gros nettoyage millenaire de phpBb. Mais au moment du topic il n'était pas encore sortie.Merci pour les infos,
je viens de regarder le code source de vbulletin et effectivement ils chargent les messages via un IN () en prenant leurs ID.
J'ai regardé le code source de phpBB3 et ils ont corrigés ce problème aussi, donc phpBB3 ne souffrira pas de ce défaut.
Me reste plus qu'à modifier la source de mon forum
Je n'ai pas compris à quoi ça servait ?
En faite, tu gères la sortie écran. En faite quand tu fais un echo tu peux retarder l'affichage écran par exemple ou orienter l'information destiné à l'écran pour l'envoyer dans une fichier.
C'est utilisé pour la gestion du cache.
Au sujet de la mise en tampon the sortie (output buffering).
Le principe est simplement que lorsqu'il est démarré : le parser garde la main à chaque ?>, ce qui optimise largement la vitesse d'execution proportionnelement au nombre de <?php ?> (notamment pour ceux qui utilisent des templates en PHP).
Si la mise en tampon de sortie n'est pas activée, il est logique que PHP rende la main à son module d'execution lorsqu'il parse un ?> (module d'execution comme apache-php, cli ou cgi, ou autre). Lequel lui rend la main si il rencontre une balise d'ouverture <?php ou <? si il en rencontre une ...
En règle générale, la bufferisation de sortie optimise largement le code.
example : http://www.developpez.net/forums/sho...&postcount=287
doc : http://php.net/outcontrol
Combien de requête par page?
Bonjour à tous!
J'ai une question pour laquelle vous pourriez peut être me répondre:
Selon vous, combien de requête SQL peut on faire au maximum par page (pour un CMS complet) ?
Comme vous devez le savoir, une seule requête pour gérer un CMS c'est un peu...
Alors pour savoir si je suis dans le bon, dites moi combien de requête est il idéal de faire AU MAXIMUM pour un site accueil des centaines de personnes simultanément.
Une idée?
Merci.
Au mieux je dirais 0 !
C'est pas facile à répondre à cette question tous dépend de la logique de la structure de la base de données. Maintenant, il faut pas arriver à 50. Tu devrais pas poser la question dans ce sens là. Il préférable de se poser la question sur la logique de metier de ton application que chercher à faire des économie de requête. Il est préférable de faire 10 requêtes optimisé qu'une requête de bourrin.
Ok merci
Je vais faire les meilleures requêtes possibles ou utiliser des caches.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager