Bonjour.

Je suis en train de faire, juste comme ça, pour le fune, un espèce de petit RPG, pas vraiment en forum, mais plus dans le style de WAAR http://waar.fr , pour ceux qui n'auraient pas lu la news)... Bref, pour une table "membres", je souhaite faire un champ qui se nommerait "inventaire" où je pourrais mettre tous les items d'un personnage... Et, dans le même style, un champ "Banque". Mon problème, comme vous voyez, n'est pas un problème de code, mais bien un problème organisationnel. En lien avec cela, j'ai aussi le problème suivant, comment je fais un OBJET en PHP! Mais je suis à peu près certain qu'il y a un tuto qui en parle quelquepart...

Si vous avez des réponses à l'une ou l'autre de mes questions, n'hésitez ni ne vous retenez pas, surtout!

Salut

Pour ton probleme organisationnel comme tu l'appelles, tu peux très bien séparer les données que tu veux inserer dans ta table par un point '.' et ensuite utiliser la fonction explode() pour créé un array contenant chaque élément de ton inventaire. Je te donne un petit exemple pour une meilleure compréhension:



Apres si tu veux récupérer le nombre le chaque élément de ton inventaire rien ne t'empeche de faire a nouveau usage de la fonction explode()

par exemple pour obtenir le nombre de potion tu fais $potions = explode(':', $inventaire[0])


Voila j'espere t'avoir aidé

C'est pile ça que je cherchais! Merci!

Bonsoir

Il est impossible, à ma connaissance, d'inclure plusieurs valeurs dans un champ (à moins que je me trompe, auquel cas je serais ravi qu'on me le fasse savoir ).
Tu peux utiliser plusieurs subterfuge, comme mettre une simple chaîne qui sépare clairement chaque item comme :


Ou sinon, tu peux, à chaque ajout d'item, jouer avec un array linéarisé dans la BDD avec serialize() et récupéré avec unserialize() :


Mais moi, à ta place, j'aurais fait une autre table "items" tel que :


C'est une base très simple. Il suffirait alors de l'adapter (ajout d'une description, d'un prix, d'un nombre maximal, ...) et de les récupérer avec un petit LEFT JOIN.


Et tu as raison, il y a bel et bien un tuto sur la POO : ici.

En espérant t'avoir aidé. Bonsoir.

Si ce serait possible mais vraiment pas pratique. Tu ferai mieux de créer plusieurs tables pour ton organisation. Ensuite par exemple pour ta table inventaire, tu rajoutes un champs id_membre contenant l'id du membre.
Après, tu utilises une jointure pour économiser les requêtes et ce sera parfait
Si tu veux plus d'infos : http://www.siteduzero.com/tuto-3-8504-1-les-jointures-moyen-d-economiser-des-ressources.html

y a serialize() pour ça

Oui, mais il vaut peut-être mieux créer deux tables distinctes plutôt que tout mettre dans un seul champs.

Enfin après je ne sais pas pour vous, mais personnellement je préfère utiliser la puissance de MySQL et de tout bien séparer. Parce que bon, lorsqu'on regarde notre base de données, ce n'est pas très facile pour s'y retrouver

Tfacon faut pas stocker plisuers valeurs dans un champs. Si tu en arrive la c'est que tu a mal concu ta base.

Ici la solution c'est : une table user, une table objet et une table de liaison (obligé car cardinalité n-n).
Dans la table de liason tu associ un id_joueur avec un id_objet.

Salut a toi

moi je te propose un tableau multidimensionnelle pour stocker tes valeurs



enfin l'utilisation de multidi n'est vraiment pas nécessaire mes je trouve que ces un moyen
ultime de bien organiser ces données mes aussi un bon moyen de s'embrouiller le cerveau

pour rentre les donnée de ta table il faut que tu regarde une fonction pour remplire ton array multi je me rapelle plus la fonction array_push je crois a verifier

djbennnyj > Peux-tu m'expliquer l'utilité d'une table liaison ? Avec les LEFT JOIN et les RIGHT JOIN, il me semble parfaitement inutile, voir risible de créer de telles tables pour chaque liaison d'un site...

Et je persiste : une seconde table pour les items sera nettement plus gérable (ajout, mise à jour, ...), d'autant plus que ta table membres deviendrait rapidement volumineuse, et tu risques ainsi de perdre des performances.
Deux tables, à mes yeux, c'est mieux en matière de gestion et de rapidité d'éxecution.

+1Twiefy
moi j'ai travailler sur un gros projet dans ma boite moin on faisait de tables mieu le programme ce portait

Citation : Twiefy

djbennnyj > Peux-tu m'expliquer l'utilité d'une table liaison ? Avec les LEFT JOIN et les RIGHT JOIN, il me semble parfaitement inutile, voir risible de créer de telles tables pour chaque liaison d'un site...

Chaque joueur peut avoir plusieurs objet, chaque objet peut etre possédé par plusieur joueur.
C'est aussi simple que ca.
Le passage par une table de liaison, est ici obligatoir, pour une base de donnée propre et correct.
Il y aura bien sur aussi besoin de JOIN etcc...
C'est de la pure logique.
Si tu ne fait pas ca tu aura soi
-redondance des informations (tres décommandé)
-Plusieurs données dans un meme champs (encore pire)


Les join etc sont valable directement SEULEMENT quand on a une cardinalite non n-n.

Essayez vous verrez

Je confirme, la table de liaison est beaucoup plus propre et plus pratique.

On mets :

Une table joueur : id du joueur + nom + divers champs pour les caractéristiques du perso

Une table items : id de l'item + nom + divers champs pour les caractéristiques de l'item (prix, propriété, etc etc... )

Une table liaison : id du joueur + id de l'item + quantité


Ca permet de référencer le tout clairement, de modifier le nombre d'items d'un certain type affecté à un joueur particulier très simplement et d'ajouter de nouveaux items au jeu tout aussi simplement.

Et avec ça, nul besoin de se prendre la tête avec des explodes...

Alors oui, ça fait une table de plus, mais franchement, c'est quand même nettement plus pratique selon moi...

Et puis la tête d'un update sur un champ ou tout serait séparé par un délimiteur

Aie! Désolé, là, mais... j'ai pas très bien compris... pour l'idée de gérer ça en relationnel, ça va, mais LEFT JOIN et RIGHT JOIN? J'imagine que ça sort tout droit du SQL, vu les majuscules, mais... comment je les utilise? Si c'est long à expliquer, svp, placez simplement un lien vers un tuto, je cherche de mon côté, pendant ce temps là...
Et qu,est-ce que une table de liaison? Bref... j'ai beaucoup à apprendre... Moi, je pensais gérer ça en POO, et envoyer dans la table la valeur retournée par serialize, puis faire unserialize pour récupérer l'objet par la suite... Mais, avec les update, comment je vais m'y prendre? Merci de votre aide à l'avance...

Bonsoir

Personnellement, je n'ai jamais utilisé RIGHT JOIN, ni jamais étudié son fonctionnement. Je ne peux pas conséquent que te dire que ça doit être assez semblable à LEFT JOIN, avec quelques différences dans le résultat final .

Pour LEFT JOIN, jette un oeil sur ce tuto.

Citation : Pas de titre

Qu'est-ce qu'une table de liaison?

La on sort completement du php, pour parler base de donnée.

Renseigne toi du cotés des cardinalités.

Si tu as une table user et une table objet, on pourai alors decrire la liason comme ca

USER --- OBJETS

- Chaque joueur peu posséder 0 ou plusieurs (nombre non fixe) objets, on dit "n" objet.
L'inverse maintenant
- Chaque objet peut être possédé par 0 ou "n" joueurs.


Pourquoi? , c'est logique.
Il est impossible de caser un champ id_user , par exemple dans la table objet, cela signifierais plusieurs donné par champ, et ce n'est pas le but d'une bdd bien construite.

La table de liaison sert a relier 2 tables, qui de part leur structures, génère des cardinalité n-n

Donc ici, il faut créer une table :

LIAISON_USER_OBJET
id id_joueur
id_objet
Nombre_objet


Imaginons un enregistrement de la table user :
id:12 user_nom: benji

Imaginons ces enregistrements de la table objet :
id: 1 nom_objet:marteau
id:2 nom_objet : tournevis
id: 3 nom_objet: perceuse
id:4 nom_objet : clou


DOnc les enregistrements de la table de liaison ressemblerai a ca :
id : 1 id_joueur: 12 id_objet: 1 nombre: 2 (benji possèdes 2 marteau)
id : 2 id_joueur: 12 id_objet: 4 nombre: 1 (benji possèdes 1 clou)



Et ainsi de suite.

La requete, ici ressemblerai a ca :




Je ne sais pas si ce que j'ai ecri est clair, mais dans le cas contraire, n'hésite pas a demander.

C'est bien clair... pour moi en tout cas Mais est-ce que ça veut dire que tous les items possibles devront êtres répertoriés dans la table Objets sans que l'on puisse ou que l'on veuille les changer, tout simplement comme une liste toute bête des objets qui existent dans le jeu?

Plus ou moins.
Tu peut par exemple faire une table objet comme ceci :

TABLE OBJETS
id
nom_objet
prix
disponible (boolean)

En gros, disponible indique si oui ou non il peu et dois etre utilisé ds ton jeu par exemple.
Et tu poura toujours ajouter des objet dans la table objet, ou les changer.

merci... Je vais bien y réfléchir!