c'est à dire?

On ta montré un système simple, facile à mettre ne place et utilisé par beaucoup d'autres personnes.

Comme je suis bon je te remontre le système que j'ai moi mit en place:

Si veux par exemple, gérer un système d'usure des objets, il suffit d'ajouté 1 champ 'usure' dans la table inventaire avec l'usure de l'objet...

C'est le meilleur système actuellement parce qu'il est léger et maniable.

Ce message a été modifié le: 08-07-2008 05:47 PM par phenix.

Ce que j'ai proposé est simple et léger, car vous ne le faite qu'une fois et cela sera bien plus rapide que de sélectionner tous les objets d'une utilisateur parmis des milliers(ou des millions) surtout si vous utilisez des sessions.
J'en ai essayé d'autre, ce n'est pas la meilleure solution pour les objets prédéfinis(mine) dont on est sur que l'utilisateur va posséder mais dans le cas d'un inventaire c'est la meilleure solution, selon moi.
el[u]ox -> Erreur ! Vous faites un while pour chaque objet, je fais un foreach pour chaque objet...c'est équivalent. Tout le monde sait faire uen concaténation j'espère et le reste je l'ai donné.
phenix -> Aucune différence réelle de maniabilité, surtout en POO.

Je sais pas si tu te rends compte de ce que tu dis...sélectionner 1.000 objets dans une table parmis des millions, tu crois que ca va etre plus rapide ?!

Satevis -> il est vrai que l'espace disque n'est pas vraiment ce qu'on paye cher en général, ce n'est pas le plus important pour moi. Seulement je pense cette solution beaucoup plus rapide pour le processeur, ca me parait en fait assez évident.

Ce message a été modifié le: 08-07-2008 07:44 PM par IGstaff.

Je sais parfaitement ce que je dis...
MySQL est fait pour gérer de grosse masse de donnée, avec des champs correctement index et des clée primaire, ce sera bien plus rapide pour retrouver afficher un objet.
Les boucles et les array de PHP ne sont pas faite pour crée de grosse masse de données.

J'arrête là la discutions, tu veux avoir raison, ok, tu as raison, personnellement je m'en fou, je sais que tu as tord.

Phenix

Question de point de vue IGstaff, à moi il me parait évident que la BDD sera plus rapide que PHP, d'un coté tu as un binaire compilé issue souvent du C et de l'autre un langage de script qui doit être interprété. Lequel des deux va plus faire souffrir le processeur aussi bien sur l'instant que cumulé sur une plus longue période ?

Un exemple tout con : C'est Noël et pour marquer le coups tu donne 5 pièces d'or à chacun des joueurs (ou un nouvel objet "Papa Noël" c'est toi qui voit ) qui sont actifs, quelle philanthrope se diront les joueurs sauf au moment où tu va lancer ton script qui va récupérer tout les joueurs actifs, explode leur inventaire, ajouter les 5 piéces d'or, implode le nouvel inventaire et fait un UPDATE, et même si tu prévoit un cron pour le faire dans la nuit tu n'es pas à l'abri que ta table crash au milieu de ton script tandis que l'autres solution te permet d'ajouter 5 pièces d'or a tout les joueurs actifs avec une seul et unique requête et ton serveur va à peine broncher...

Après chacun ses recettes de cuisine, l'important est d'être content de ce qu'on réalise au final .

mwouais... donc le carquois avec 50 fleches... 50 enregistrements? (51 avec le carquois )
tu vas me dire: "des archers, t'en aura pas bcp"... possible...

les pièces d'or, exit... je vois mal un enregistrement par pièce...
Mais bon, pour le reste, oui, pourquoi pas...

vais réfléchir a tout ca, moi, suis crevé... et rien pondu comme code today :(

Phenix: Fais ce que tu veux.

J'ai fais un VRAI benchmark(modèle d'oxman) de ces requetes car je pense que si nous développons nos idées, nous pouvons mieux nous exprimer.
J'ai créé 100 users avec 100 objets chacun soit 10.000 objets au total.
Le résultat est:
"Temps de chargement de l'utilisateur: 6.19888305664E-5 seconde.
Temps de chargement de l'inventaire par une autre table(Méthode que vous avez proposé): 0.000324964523315 seconde.
Temps de chargement de l'inventaire par un champs de la table user(Méthode que j'ai proposée): 0.000234842300415 seconde."

Je précise que lors du premier SELECT de l'inventaire sur un autre table, cela a pris 0.000762939453125 seconde soit le temps nécessaire quand les données viennent d'être insérées ou modifiées.

Je maintiens donc ce que j'ai dis avec des preuves.
je tiens à préciser que globalement les temps sont très proches de ceux-ci.

Précision supplémentaire: Je n'ai jamais ajouté 5 pièces d'or à tous les joueurs(ou quelconque équivalent), cela ne se fait pas et ce système est bon pour les inventaires mais je conseilles quand même de mettre les ressources à part car on est sur que l'utilisateur va en posséder ou il y a de grandes chances.

Ce message a été modifié le: 08-07-2008 10:18 PM par IGstaff.

Coucou Igstaff .

Manifestement tu as un système fiable et robuste. Si tu en es content garde le.

kéké

On fait ce qu'on peut pour avoir une bonne réputation lol.
J'attends d'avoir les scripts SQL pour avoir des tables avec clés étrangères pour tester car cela se montre assez intéressant...
Comme j'en ai parlé dans 2 ou 3 postes précédent et que Eluox n'a pas compris, ce système n'est valable que pour certains cas comme les inventaires, autrement je pense que chacun doit avoir son champs dans la table...

Il me semble que dans tous les cas la BDD s'impose ... mais c'est plus histoire d'avoir une homogénéité dans la méthode et un interfaçage simple et rapide que pour le reste.

Par exemple, dans Magdales, si je découvre qu'il y a un problème lié à un objet (une épée qui est trop puissante par exemple) je peux modifier toutes la base en une requête. Or chaque objets peut-être unique ... Un même type d'épée peut avoir plusieurs valeurs puissance.

Mais je ne connais pas toutes les contraintes liées à ton jeu ... fais comme bon te semble.

kéké