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 ?
Version imprimable
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 !...Citation:
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.Citation:
Envoy� par Blustuff
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.Citation:
Envoy� par Blustuff
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.Citation:
Envoy� par Blustuff
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.Citation:
Envoy� par Blustuff
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 ^^Citation:
Envoy� par berceker united
C'est simple PhpBb utilise le LIMIT :aie: c'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 ;) .Citation:
Envoy� par genova
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 :mrgreen:
PhpBb3 est apparement un tr�s gros nettoyage millenaire de phpBb. Mais au moment du topic il n'�tait pas encore sortie.Citation:
Envoy� par genova
Je n'ai pas compris � quoi �a servait ?Citation:
Envoy� par Metallic-84s
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.Citation:
Envoy� par afrodje
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
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 !Citation:
Envoy� par Sayrus
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.