Il y aussi des soucis d'homogénéité. Le jour ou tu voudra faire une page de stats avec tes objets.....

Il te faudra taper la moitie dans la bdd, l'autre moiti des infos ailleurs. Enfin bon c'est du grand n'importe quoi

Le problème ne se situe pas au niveau des performances, mais bel et bien de la conception même du système.
Quand on construit un système, sur quoi on doit s'attarder ?
Une des choses et sa capacité à évoluer, explode/implode, c'est marcher avec une jambe en bois.

Admettons que pour des besoins précis tu ai besoin de savoir le nombre d'Arc zygoton qui sont en jeux, tu vas faire comment avec ton explode ?

A quoi pourrait servir de savoir ça ? Tout simplement pour des besoins d'équilibrages du jeu, de dénombrement pour connaitre les gouts des joueurs, enfin il y a mille raisons.

Je ne t'ai donné qu'un exemple très bateau, qui serait déjà bien plus chiant à faire à cause de tes explode/implode, si je te dis maintenant que je veux le dénombrement de chaque objet là ça n'est vraiment plus comparable, très trivial en base de données, lourd et chiant dans ton système qui n'est pas du tout adaptée.

Autre cas bidon, tu as besoin de savoir le nombre d'or qui circule dans ton jeu car il faut que tu définisse où se situe l'équilibre financier de ce dernier, si il y a trop d'or en jeu, pas assez etc, et rebelote, c'est le bordel.

De plus, j'ai vu des trucs amusants, qui parle de mettre une ligne par pièce d'or ? une ligne par flèches ?
N'importe quoi. Il suffit de mettre une case quantité pour tous les objets, ainsi tu peux avoir 500 pièces d'Or en une ligne, 300 flèches en une ligne, etc.

Et ça permet d'avoir 10x Arc Zygoton, si ça n'as pas forcément de logique en sens propre, 10x bout de charbon ça en a plus


Edit :
Tiens j'adore l'exemple de Satevis aussi sur le fait de donner 5 pièces d'or à Noël à tes joueurs, et là encore, gros boxon avec tes implodes/explodes, ça prend 2 sec en SQL. Les implode/explode "dans les bases" c'est bien parfois, mais pour ce cas précis ça n'est PAS DU TOUT adapté, les données sont beaucoup beaucoup trop dynamiques.

keke -> je ne pesne pas que ce soit al question ici et Il me semble que Ruz m'a confirmé que ce ne sont pas les cractéristiques des bojets ui lui posent problème et ce n'est pas de ce que j'ai traité mais le stockage des objets pour chaque joueur ce qui est proche mais ne focntionen aps sur le meme principe.
Un joueur utilise des objets créé dans un fichier ou une table et les met dans son inventaire, c'est comment va etre stocker l'inventaire qui nous intéresse.

Hum ... zygoton .. je connais pas. Parles tu des fameux arc Zigotone ?

http://fr.wikipedia.org/wiki/Arc_zigotone

Kéké

@oxman: ok... pas une ligne par flèche... ni par PO
=> retour case départ: comment gères-tu deux armures de cuir avec des taux d'usure différents?

tu parles bcp, en très succin, mais tu n'as encore rien proposé, que je sache, je me trompe?
oui, on cherche une solution de stockage d'inventaire... on se fiche des caracs des objets, c'est un autre point non abordé.
l'inventaire tient compte:
1) qu'un joueur peut avoir plusieurs copies d'un meme objet. (champ "quantité" ou 1 ligne/objet)
2) que ces copies peuvent avoir des taux d'usure différents (armure/arme)

A part mettre une ligne par objet... j'attends ta solution
[sinon, retour premier message: mon système hybride actuel (lourd niveau code), auquel je cherche une meilleure alternative
rappel système actuel:
tout sauf armure/arme : ID, ID_perso, ID_objet, Qtt, Uusure (inutilisé)
armure/arme (une ligne par enregistrement) : ID, ID_perso, ID_objet, Qtt (1), Usure ]

Il est clair que l'utilisation d'un tableau, avec toutes une série de concaténation et la solution la plus simple à mettre en oeuvre mais alors dès qu'il s'agit de manipuler ses données cela va vite devenir un enfer et je vous parle pas de l'intégrité des données. De plus, la structure de contrôle foreach est la plus longue en terme de temps de traitement; pour atteindre le temps de traitement d'un while ou d'un for vaut mieux utiliser cette combinaison : while(list($key, $value, ...) = each())

Comme le dit Oxman, les données sont dynamiques, de ce fait la base de données est la solution la plus sûre et surtout la plus évolutive et manipulable.

Toutefois, discuter, argumenter, contre-argumenter pour ceci et pour cela n'est pas suffisant. Je ne vois aucunement de modélisation de toutes ses argumentations, les dessins sont tellement plus facile à comprendre

Commençons par structurer l'idée :

On a besoin d'un objet Joueur, forcément sans joueur pas de jeu.
On a besoin d'un objet Inventaire, pour stocker les objets que ramassera le joueur.
On a besoin d'un objet Objet, forcément sans objet pas d'inventaire.

A partir de ce moment là, Ruz, on remarque une chose c'est que tu as fait un amalgame entre inventaire et équipement.

On a donc besoin d'un objet Equipement pour gérer ce que porte le joueur et surtout gérer plus aisément l'usure des objets.

On se retrouve donc, avec 4 tables pour la base de notre modélisation.
Joueur(id, nom, email)
Objet(id, type, `sous-type`, crc1, crc2, etc...)
Inventaire(id, #id_Joueur, #id_Objet, quantite, usure)
Equipement(id, #id_Joueur, #id_Inventaire, usure)

Vous me direz mais comment gère-t-on les dégâts car c'est bien là le problème du sujet initiale.
Tout d'abord posons-nous la question de comment nous allons reconnaitre cet objet usé d'un autre même objet non usé, cela se fait de façon simple, les objets pouvant comporter de l'usure ne sont pas empilable car sinon la distinction devient impossible. Ce qui revient à dire les armures et les armes ne doivent pas être empilable.

Modélisation :


Maintenant, est-ce que cette démarche répond au problème ?

Ruz, pour information je ne connaissais pas du tout le problème, je réagissais juste aux derniers messages que j'ai lut.
Et donc, concernant le problème, voici la solution que j'utiliserais :

Tous les objets ne sont pas dit "stackables", ceux qui ne se stack pas sont ceux qui justement ont des propriétés propres en plus.

Cas par exemple de tes armures.

Et donc tu as ta table objet :

Et donc tu as ensuite ta table inventaire :

Ce qui peut ne pas etre adapté si tu as 80% des objets sans USURE, dans ce cas tu fais plutôt :

Et tu as une table usure :

Pas besoin de 3 tables, avec 2 cela suffit amplement.

J'ai d'abord ma table item, qui contient tous les objets existant avec leur caractéristiques, et la table inventaire qui se compose comme ça :

-id_joueur
-id_item
-nombre (alors le nombre, pour tout ce qui est potion, matériaux etc...il n'y a qu'une ligne pour tous les objets (un ligne par objet différent) du joueur Ex: Potion de vie X155, Charbon X20 etc..., pour tous les équipements, outils etc...il y a une ligne par objet, afin de traiter l'usure sur chaque objet)
-port (1=équipé, 0=déséquipé)
-matricule (permet de différencier chaque objet, pareil qu'un id)
-etat (l'usure de chaque objet, champ vide pour les potions et autres)

Je vois pas pourquoi vous parlez d'explode et de toute cette m****, alors qu'il n'y a rien de compliqué...

Pour l'or, j'ai juste mis un champ dans la table membre, et si je devais traiter les flèches se serait de la même façon que le spotions et autre.

Oui Kassak, donc tu considères que tous les objets sont usables ?
Ca tu n'en sais rien, tu ne connais pas son jeu, il y a beaucoup de jeux où seulement un certain équipement l'est, c'est pour ça que je donne les deux solutions.

Si plus de 50% des objets qui seront dans les inventaires sont usables, alors deux tables suffisent.
Sinon il faut sans doute utiliser 3 tables pour ne pas surcharger les tables de données inutiles (à savoir une colonne "usure" très peu utilisée).

Si on suit ta logique Kassak, pour toi un objet équipé par le joueur est un objet toujours présent dans l'inventaire ?
Il n'y a pas quelque chose qui te choque ?