[Gestion inventaire] ID unique, ou non?

[Ruz]

@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 ]

[z3d]

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 :haha:

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 ?

[Kassak]

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.

[z3d]

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 ?

[Cartman34]

z3d -> el[u]ox a voulu faire une modélisation de ma bdd de test en y ajoutant les clés étrangères, seulement ses scripts SQL en fonctionnent jamais, on pourrait en parler plus sérieusement que je fasses des test voir si mysql pourrait faire mieux ?
Cette histoire m'intéresse mais rien ne fonctionne.
Voici les tables que j'utilise actuellement pour comparer:

Code PHP :

<?php 

CREATE TABLE `users` (

`id` INT( 10 ) NOT NULL AUTO_INCREMENT ,

`name` VARCHAR( 50 ) NOT NULL ,

`password` VARCHAR( 40 ) NOT NULL ,

`email` VARCHAR( 50 ) NOT NULL ,

`inventory` TEXT NOT NULL ,

PRIMARY KEY ( `id` )

) ENGINE = MYISAM



 CREATE TABLE `inventory` (

`id` INT( 10 ) NOT NULL AUTO_INCREMENT ,

`user_id` INT( 10 ) NOT NULL ,

`object_id` INT( 10 ) NOT NULL ,

`number` INT( 10 ) NOT NULL ,

PRIMARY KEY ( `id` ) ,

INDEX ( `user_id` , `object_id` )

) ENGINE = MYISAM 

[Kassak]

Zed, pour moi l'inventaire c'est ce que le personnage a sur lui, donc équipé ou non équipé, et ensuite un champ port comme je l'ai fait suffit amplement, pourquoi refaire une autre table alors qu'un champ suffit?

Oxman, mon champ usure, appelé etat dans mon cas, me sert a beaucoup de chose. Un objet a l'état normal, c'est l'objet ayant les caracs que j'ai mise en bdd, ensuite les états inférieur à normal, auront un effet négatif lors de l'utilisation ( que se soit équipement ou potion ), et vice versa pour un effet supérieur à normal.

De toute façon, chacun a sa manière de faire, il n'y a pas de bonne ou de mauvaise

[keke]

De toute façon, chacun a sa manière de faire, il n'y a pas de bonne ou de mauvaise

A toi aussi tu cherches à te rattraper d'un topic foireux ?
Ben je te rejoins sur plusieurs point Kassak car c'est ainsi que j'ai procédé.
Un objet est transporté par un joueur. Il peut être utilisé ou non. J'indique aussi si l'objet est dans un sac à dos ou non ... mais je n'ai qu'une table objet

Dans mes tables j'ai plusieurs colonne qui ne sont pratiquement pas utilisés ... Je n'ai pas mis d'usure car je compte cet état comme un 'Effet' et ça suit un module en cours de développement qui est plus large.

Dans ma table Objet, j'ai beaucoup de champs qui sont peu utilisés... enfin, utilisés uniquement pour certains types d'objets :
Exemple : beaucoup d'objet sont non-empillable (une colonne de 1 octet pour indiquer empillable ou non), mais ces objets on aussi un champs nombre ... ce qui peut faire double emploi. Tous les objets ont un champs dommage qui n'est normalement que réservé aux armes. Les objets ont tous un champs id_rangement qui sert à désigner l'endroit ou l'on peut poser son heaume, son armure, son arme ... le sac de couchage a un rangement à 0 comme beaucoup d'objet.

Ma table objet est certes énormes ... mais mes requêtes sont très simples ... et ça marche depuis 3 ans.

Kéké

[Ruz]

ok, merci pour les réponses... Je rentre chez moi voir ca, et je cogite un peu ce soir...

[Satevis]

J'ai donné une solution mais personne ne m'écoute :'( mais je n'avais pas de jolie dessin peut être pour çà .

Petite idée qui n'est surement pas la meilleure voir la bonne .
-Ta table 'Objet', tout les types objets disponible avec leurs caractéristiques toussa toussa ce qui nous donne l'ID_Objet.
-Ta table 'Inventaire' qui lie un ID_Objet à un ID_Joueur plus les infos complémentaires genre la quantité si équipé ou pas toussa toussa qui nous donne ID_inventaire.
-1 table 'UsureObjet' qui associe un ID_Inventaire à la valeur d'usure si l'objet en à une. Exemple : si tu as 5 épées tu insères 5 ligne, pour l'or pas la peine de l'y ajouter puisque pas d'usure.

Au final tout le monde (a part IGstaff ) à la même solution ou presque.

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())

C'est le contraire justement .

[phenix]

Et le plus rapide est :
$key = array_keys($aHash);
$size = sizeOf($key);
for ($i=0; $i<$size; $i++) $tmp[] = &$aHash[$key[$i]];

Heu ce serai pas:

Code PHP :

<?php 

$key = array_keys($aHash);

$size = sizeOf($key);

$i=0;

while ($i<$size) {

$tmp[] = &$aHash[$key[$i]];

$i++;

}