Système d'inventaires BDD

[Kihmé]

tu n'as pas besoin de champ nombre. Dans ta table Item tu fais une requète de type select count(id) where type = 'potion' où potion peut être une clé étrangère et ça te renverra le nombre de potion. Ne jamais stocker une information (par exemple ton nombre) qui peut s'obtenir par une fonction (ou un calcul).

pas du tout d'accord, si on a un inventaire avec possibilité d'empiler (exemple empiler des potions de soin, des pièces d'or, etc... cas typique tous les mmo) le champ quantité à tout son sens. Tout dépend donc de ce qu'il veut faire

Quand je dis "Ne jamais stocker une information (par exemple ton nombre) qui peut s'obtenir par une fonction (ou un calcul)." il s'agit d'une convention, c'est une règle de modélisation, il ne s'agit pas de mon avis. En y dérogeant on expose la bdd à de la redondance, OUCH!!! On se situe dans un cas général, après tu parles d'un cas particulier qu'est le mmo et de l'empilage, je n'ai pas bien compris ce que c'est. Même si toute règle est contournable, reste à savoir si ça en vaut la peine...

Dans le cas d'une table Acheter, issus de la relation many to many d'une table Item et d'une autre User alors oui, il pourrait en fonction du cahier des charges être utile de placer un champ quantité mais souvent, il sera privilégié un tuple par item acheté puisque gérer tous les items achetés en même temps dans un tuple empêchera la distinction entre chacun d'eux. Mais je n'ai pas l'impression qu'on soit dans ce cas ci.

[niahoo]

euh non ..

tu racontes n'importe quoi.

Stocker des données qui pourraient être calculées n'implique pas de redondance. Et c'est très bien de pas avoir a tout recalculer tout le temps.
enfin, ça dépends ce que tu veux optimiser: performance, maintenance, évolutivité, etc..

Moi je voudrais voir ta source pour cette « convention de modélisation »

[atra27]

Hum sinon on fait simplement une table inventory avec:
id (autoincrement etc) idjoueur idobject type quantity

On peut rajouter d'autres champs... perso j'utilise(*ait) un autre champ place pour différencier les différents inventaires et les objets équipés.

Ensuite simplement a l'achat:
un petit INSERT ONDUPLICATE KEY UPDATE (car idjoueur, idobject et type indexés)

Et a la vente/utilisation:
Si quantité en stock > quantité demandée
UPDATE quantity=quantity-quantité demandée
Si quantité en stock == quantité demandée
DELETE du champ de cet objet
Sinon
Message d'erreur (objet pas en inventaire ou pas en quandtité suffisante)

J'espère avoir été clair...

[Kihmé]

oui j'ai dis une connerie pour la redondance. J'avais en tête un exemple qui provoquait ça et je l'ai pris pour un cas général.

Pour la source, tu chercheras, j'ai appris ça en BTS dans les règles de modélisation, factorisation des données par exemple. Il faut toujours factoriser au maximum, ne pas utiliser 1 tuple pour y stocker plusieurs item alors que tu peux les factoriser en plusieurs.

Je me cite du message d'avant qui explique :

Dans le cas d'une table Acheter, issus de la relation many to many d'une table Item et d'une autre User alors oui, il pourrait en fonction du cahier des charges être utile de placer un champ quantité mais souvent, il sera privilégié un tuple par item acheté puisque gérer tous les items achetés en même temps dans un tuple empêchera la distinction entre chacun d'eux. Mais je n'ai pas l'impression qu'on soit dans ce cas ci.

J'ai essayé de voir pourquoi tu restes sur ton idée du champs nombre, tu parlais de potion et de pièces, il n'est pas utilise des les différencier donc je comprend que tu veuilles utilises un champs pour le nombre. Mais que fais tu si tu as d'autre objet qui ont besoin d'une différentiation? Des épées, de même nom, mais avec des usures différentes???

Faut vraiment que je trouve ça sur une vrai source, car on va pas s'en sortir mais stocker une information que tu peux avoir par une fonction sql est une erreur de modélisation... Si le calcul est trop fastidieux et répétitif tu as l'option d'utiliser une vue.

[aurlien]

donc si je comprend bien le mieux serait :

une table pour tous le personnage ainsi que les ID correspondant au item
une table avec tous items du jeu
une table ou tous les items des joueurs sont présent

et on relis sa avec des id ?
j'ai compris ou je suis à la ramasse ?

---

Donc si un perso a 20 items dans son inventaire il y aura 20 champs pour chaque item et un qui aura l'option équipé...... (pour des épées par exemple...)
juste un peu de modélisation c'est pas si compliquée que sa
(par contre niveau prog sa va prendre plusieurs lignes xD )

[niahoo]

genre « tu chercheras ».

Ok donc le mec va acheter 10 000 unités d'uranium et toi tu vas caler 10 000 tuples dans ta table. heureusement que tu « comprends » pourquoi je ne veux pas le faire !

Fin bref, on est d'accord sur le fond. Il est utile de stocker un nombre, une quantité quand les items sont les mêmes. Toi tu trouves que c'est acceptable, et moi je trouve que c'est évident.

Ensuite, pour les items qui ont de l'usure bah tu fais comme dans wow ou eve, au hasard: ils ne se stackent plus, ont un identifiant unique, et toutes les valeurs que tu voudrais y associer, car la la modélisation t'oblige à les rendre unique. Mais je parle bien de la modélisation et pas du choix d'utilser une, deux tables, 5 ou 7 champs, une clé étrangère ou non, etc..

Comme d'hab, tout dépends du jeu, si les types on jamais plus de 3 objets dans leur inventaire, tu peux y aller. mais pour mon uranium la base de données va pas kiffer.


"""
et on relis sa avec des id ?
j'ai compris ou je suis à la ramasse ?
""""

Non, c'est bien ça !

[aurlien]

Oki mercis à tous pour votre aide, si jamais dans le script je tombe sur une ereur j'en fais part mais maintenant j'ai comprid le système

[Kihmé]

genre « tu chercheras ».

Ok donc le mec va acheter 10 000 unités d'uranium et toi tu vas caler 10 000 tuples dans ta table. heureusement que tu « comprends » pourquoi je ne veux pas le faire !

Fin bref, on est d'accord sur le fond. Il est utile de stocker un nombre, une quantité quand les items sont les mêmes. Toi tu trouves que c'est acceptable, et moi je trouve que c'est évident.

Ensuite, pour les items qui ont de l'usure bah tu fais comme dans wow ou eve, au hasard: ils ne se stackent plus, ont un identifiant unique, et toutes les valeurs que tu voudrais y associer, car la la modélisation t'oblige à les rendre unique. Mais je parle bien de la modélisation et pas du choix d'utilser une, deux tables, 5 ou 7 champs, une clé étrangère ou non, etc..

Comme d'hab, tout dépends du jeu, si les types on jamais plus de 3 objets dans leur inventaire, tu peux y aller. mais pour mon uranium la base de données va pas kiffer.


"""
et on relis sa avec des id ?
j'ai compris ou je suis à la ramasse ?
""""

Non, c'est bien ça !

L'uranium n'est pas un item, et au final l'argent non plus. Donc en fait on est en train de se mélanger. Je parle de quelque chose, toi d'une autre.

Ton uranium n'est pas un item (après ça va dépendre des contextes) mais tu n'as pas de table uranium. Tu as un champs uranium de type numérique dans ta table joueur.
Pour l'argent c'est pareil. Donc ce ne sont pas des items.

Les potions vont avoir une relation de type many to many entre le type de potion et le joueur donc pareil champs numérique dans la table issus de la relation. Donc ce ne sont pas des items.

Après faudrait voir son cahier des charges pour être sur.

[Ter Rowan]

L'uranium n'est pas un item, et au final l'argent non plus. Donc en fait on est en train de se mélanger. Je parle de quelque chose, toi d'une autre.

Ton uranium n'est pas un item (après ça va dépendre des contextes) mais tu n'as pas de table uranium. Tu as un champs uranium de type numérique dans ta table joueur.
Pour l'argent c'est pareil. Donc ce ne sont pas des items.

Les potions vont avoir une relation de type many to many entre le type de potion et le joueur donc pareil champs numérique dans la table issus de la relation. Donc ce ne sont pas des items.

Après faudrait voir son cahier des charges pour être sur.

je trouve tes "donc" très extrêmes

la multiplication des tables (exemple potion) n'est pas non plus pertinente
de même créer un champ pour chaque ressource de base(ex uranium) n'est pas pertinent, à moins de modifier le modèle à chaque création de nouvelle ressource (ce qui me semble très souvent une anomalie

tu peux très bien avoir une table avec

id perso / type d'item / quantité / indicateur (dans ton exemple usure)

du coup si tu as 10 potions ça donne

perso1 / potion / 10 / 100

on peut même imaginer qu'on ait 3 autres potions un peu "vieilles"

perso1 / potion / 3 / 60

de même si tu as une épée ébréchée et une autre toute neuve

perso1 / épée / 1 / 40
perso1 / épée / 1 / 100

et encore, si tu as 30 minerais d'uranium et 5 lingots d'uranium mal raffiné

perso1 / minerai uranium / 30 / 100
perso1 / lingot uranium / 5 / 60


je ne pense pas que ce système soit particulièrement anormal pour Merise (ouhouh le jeu de mot, les formes normales, houhou)

du coup il suffit d'une simple requête pour sortir l'inventaire, et avec un pattern factory tu génères les instances qui vont bien (et qui interprèteront chacun différemment la valeur de l'indicateur : l'épée fera moins de dégât, risquera de se casser, la potion fera moins d'effet, l'utilisation des lingots d'uranium fera de mauvais objets, etc...)

[Kihmé]

Ter Rowan ça revient à ce que je dis en fait, tu n'as pas de champs de quantité dans la table Item, ce que tu fais c'est le cas dont je parlais pour les many to many.