Gros volume d'informations

[berceker united]

Bonjour.
Toujours dans le cadre de mon application je me pose la question de "Oui mais si les utilisateurs ajoutes des milliers de produits ?" Bien souvent nous faisons de test sur quelques produit mais lorsque ça atteind des centaines de milliers comme le système se comporte surtout dans le cas de l'utilisation d'un limite?
J'ai pensé à utiliser une table déporté qui lui va contenir que les id de la table principale.
SELECT id FROM tb_deporte LIMIT 1257000, 10
SELECT * FROM tb_normal WHERE monchamps IN(mes id retourné ci-dessus)

est-ce une bonne idée ou non ?

[Amara]

Tu dupliques les infos en faisant ça nan
Et ça fait comme une jointure, à mon avis ça tire plus qu'en faisant une requête classique (mais je suis pas spécialiste BDD, d'ailleurs ta question aurait de meilleures réponses en postant chez eux )

PS : pour ta signature je me suis pas mal demandé d'où ça venais et c'était à la télé l'autre soir mdr en entendant ça

[berceker united]

Oui ça duplique uniquement l'id et effectivement c'est pas terrible mais apparement c'est un problème qui devient très important lors de l'utilisation d'un limite sur du gros volume.

[rbaatouc]

kan ya de gros volume fo savoir otpimiser aussi comme pour ton code :
- placement intelligent d'index dans tes tables
- activer le query cache (dispo seulemtna partir de mysql 4.0.1 je crois)
- optimiser la structure des tables

voici un lien qui texplique un peu tout ça :
http://dev.mysql.com/doc/refman/5.0/...structure.html

[ePoX]

Je regrette un peu que tu n'exposes pas plus clairement ton problème :/
Car à part balancer des réponses bateau, même utile, je ne voit pas trop comment t'aider.....

D'ailleurs dans le genre réponses bateau, as tu pensé à revoir la structure de ta bdd ?

[berceker united]

Pour l'instant je n'ai pas de problème et je ne pense pas que la structure de mes soit mauvaise car j'ai fais en sorte de dispatcher élément redondant et placé les index sur les éléments pivot. Plus utiliser des valeurs numérique. Mais essayez de faire un limit ver la fin sur une table qui compte plus d'un millions d'enregistrement vous verrez que ça peut ramer. Surtout que sous SQLServer ça n'existe pas il faut ruser (j'ai utilisé la methode trouvé ici). Idem lorsqu'il y a une recherche à effectuer avec l'opérateur LIKE qui assez gourmand.

[NoT]

J'ai parcouru ton post vite fait et je me trompes peut-être mais il me semble que ce que tu fais n'est ni plus ni moins que de recréer un index manuellement sur un des champs de ta base, alors que la plupart des bases de données le propose en natif, tu devrais t'intéresser à cette histoire d'index, ça améliore considérablement les accès dès que la table devient bien rempli.

[berceker united]

Apparement de ce que j'ai lu sur un autre forum PhpBb avait se problème du faite que lorsqu'il y avait un gros volume de données + l'utilisation du LIMIT. Le developpeur du forum "MesDiscutions" a lui contourné le problème en utilisant le systeme cité au dessus. C'est de là que je m'interroge sur ce qu'il risque d'arriver lorsqu'il y a un gros volume. De toute façon il faut que je fasse des test en y enregistrant des millions d'enregistement pour voir le comportement et faire des optimisation.

[ePoX]

Le système dont tu parles plus haut peut provoquer une dégradation de l'intégrité des données.
En effet pour peu qu'une action soit oubliée ou que sais je encore, tu pourrais te retrouver avec des index qui ne devrait plus exister, par exemple.

Sinon sur le principe dans les cas particuliers ou l'on à vraiment pas d'autre choix c'est effectivement la méthode à adopter.
Mais encore une fois je me permet d'insister, car ton projet n'est pas encore en production, essaie de repenser ton schéma, voir même à l'orientation globale du projet. Ceci afin de prendre en compte dès le départ cette problématique et d'y apporter les solutions les plus saines et adéquats possible.

Enfin je me permet juste une petite note. En effet des milliers d'items avec n relations cela reste physiquement gérable par une machine **normale**, alors que des millions d'items avec n relations, l'ordre de grandeur n'est vraiment plus du tout le même.
Et dans le cas de millions d'items ta question n'à plus rien à faire ici à mon sens, car il te faudra bien plus qu'une simple optimisation du code.

bbye

[berceker united]

En faite, le millions d'enregistrement pour mon projet me parait assez démesuré Je pense qu'a ça va jamais atteindre le milliers pour le coeur du system et c'est déjà énorme. J'ai déjà pensé à des mécanismes pour réduire les jointures via des objet déjà en mémoire partagé.

[Amara]

Bah ça va si tu as moins de 1000 enregistrements devrait pas y avoir de souci alors... C'est quedal... Enfin à mon avis, reste à voir effectivement ce que ça donne en fonctionnement mais bon...

[boo64]

+1 JWhite c clair c quedal mille enregistrements...en principe t'auras pas de probleme de temps

[berceker united]

1000 c'est mon avis. En faite je fais une application e-commerce et je ne connais pas de site ayant plus de 1000 produit en ligne sauf gros compte telle qu'Amazon ou 3 suisse la redoute. Néanmoins je voudrais prouver que le systeme est garable jusqu'a x articles avec coéficient de complexité moyennement élevé.