Pour ce qui est du portage mysql oracle, le problème ne vient pas du fait qu'il y ai des types différents (pas de text, utilisation de varchar2 et non varchar, l'auto increment c'est mysql donc à remplacer par une série et un. Tricher nèfle insert etc). Le problème vient des choses "propriétaire" des sgbd. Par exemple mysql implémente limit, qui 'existe pas chez oracle. Mais en fouillant bien tu trouvera une clause similaire (rows quelque chose).
Et c'est la que la portabilité est réduite car généralement les requêtes sont écrite en dur dans le code.
Pour éviter cela tu peux utilisé un ORM qui va te créer tes requêtes en fonction du sgbd ;)

Sinon dans ton cas je te conseillerais de créer des vue contenant le code "proprietaire" et d'utiliser ces vues à partir de php. Comme ça pas de soucis les requêtes sont toujours les mêmes :)

Côté insertion pas d'insert multiple pour oracle, c'est pas vraiment gênant, update / delete c'est pareil.

Le plus gros travail c'est de mettre en forme les données (un bon éditeur de texte qui cherche et remplace tout ;) ).

Pour la poo, cela te permet d'avoir ton modèle dans le code "comme" dans la base ça te permet de bien suivre ce que tu fait.
Après il y a la compartimentation du code et ça t'evite la tentation de créer une classe item qui va les affichées? Les modifier etc. Une telle classe existes mais pas sous ce nom (itemdao par exemple) un item c'est Les fameux pour dont j'ai parlé avant.

Avant de te lancer je te conseil de regarder quelque tuto sur la modélisation d'application. Et sur la poo (par exemple les design pattern très utile).

Enfin bref poo oui c'est bon, mais seulement si tu ne te perd pas sinon ça va être le merdier et tu va t'y perdre (perso j'ai du mal à me retrouver sur les premiers projets perso sans aucune modélisation ;) )

@+

merci bcp, je n'étais pas au courant pour le mysql"i", c'est bon à savoir :-)

sinon j'ai regardé PDO ça a l'air intéressant, notamment car la base risque de devoir être portable sur de l'Oracle.
après, les types sont différents sur les bases, donc il est clair que les requêtes seront différentes, mais si déjà les appels (fonctions) sont les mêmes, c'est un temps considérable de gagné.

actuellement au bureau j'ai développé un intranet sur MySQL, et on me demande de porter tout sur Oracle, donc il va falloir que je regarder comment convertir l'intégralité de mon code 'à l'ancienne' de mysql vers oracle, et à priori c'est pas gagné :p
donc à l'avenir dans mes projets, j'aimerais éviter ça =) ou tout faire pour réduire le travail évidemment.

quant à la POO, j'y réfléchis justement, ça peut être intéressant d'utiliser les classes pour toute la partie personnage/item & compagnie, faut que je regarde comment interfacer ça avec la base de données, mais je pense que le code sera + lisible en plus de ça, ça ne peut être que bénéfique j'espère.

merci :)

[quote="olivierg"]recommendez vous d'utiliser un framework particulier[/quote]

Pas forcément, tu peux très bien utiliser un framework que tu a fait toi même :)

si tu développe tous seul tu peux faire comme tu veux, c'est pas un soucis :)

Si tu souhaite être aider (maintenant ou plus tard) c'est mieux si tu utilise quelque chose de structuré, pas forcément de la poo mais structuré de façon à ce que tout le monde utilise les mêmes composants pour les mêmes choses.

La l'avantage de la poo c'est que la modélisation de la chose est faite, tu peux répartir simplement et rapidement les composants entre les différents dev.

Un framework va t'aider dans le sens où tu n'auras pas a développer la mécanique de l'application web (le MVC) tu n'aura a faire que les vue et les controleurs.

tu peux t'en passer et t'orienter vers un dev perso qui fera la gestion des vue et des controleurs.

Coté code oublie l'extension mysql elle est déprécié et plus maintenue, oriente toi vers l'extension mysqli (en général y a juste le [b]i[/b] à ajouter dans les fonctions :mrgreen:

tu peux aussi te tourner vers PDO, coté abstraction du SGBD, sauf si tu code des requêtes avec des fonctions propriétaires, tu feras rapidement de l'universel (bon un peux utopique mais réalisable ;) )

@+

j'imagine oui.

et là ce n'est qu'une ébauche de ce que je veux faire, mais j'ai 10 fois plus de choses à intégrer dans mon schéma, beaucoup de colonnes en plus etc.

je vais m'amuser à faire fonctionner tout cela en PHP =)

d'ailleurs, je code toujours "à l'ancienne" (sans IDE ou framework particulier), sous vi avec les fonctions de base (mysql_connect, mysql_fetch_assoc & co)

recommendez vous d'utiliser un framework particulier (du genre zend ou autre) ? pour la portabilité/compatibilité du code source ou autre raison ? (j'ai regardé zend mais ça a l'air vachement Lourd xd)

[quote="Mazarini"]Par exemple, un item peut appartenir à quelqu'un ou être stocké dans un "stockage".
Dans le second cas, tu vas gérer l'accès au stockage selon le personnage et pas la propriété de l'item. Tu pourras ainsi définir un coffre en banque, un inventaire du personnage. Toute opération sur la propriété de l'item ne sera que le transfert d'un lieu de stockage à un autre. Pour équiper un casque, il peut suffire de définir la tête de personnage comme un lieu de stockage. Il apparait alors qu'un lieu de stockage peut être limité en quantité voir en type d'item.[/quote]

le stockage j'ai fait simple avec un (des) sac(s).
ceci dit tant qu'il s'agit de sac ou de banque d'un perso, la notion de propriété reste.

Après si l'on parle de guilde, effectivement un perso n'est plus propriétaire et la pour le coup c'est la guilde qui devient propriétaire de l'objet.

Donc il est possible de définir une entité plus large (propriétaire) qui aura un type guilde / perso et après ben jointure dynamique O_o la je sais pas faire mais c'est surement réalisable ^^


Pour le coup des emplacement je n'ai pas fait, mais le modèle reste le même, c'est effectivement un "stockage" différent. après c'est un cas non traité ici.


Pour ce qui est des items à conserver ou pas, je suis partis du principe que le loot était complètement aléatoire parmi les stats proposée.

Sinon oui autant avoir une base fixe d'items (même énorme) et éviter d'en créer à la louche :)

La modélisation reste toujours suggestive, cela dépend du cahier des charges et des gens qui modélise.

Ici on parle d'une modèle relationnel et non d'un modèle objet complet de l'application, ça peu changer des petites chose.


@+

Bonjour,

Il y a tout un tas de question à se poser.

Par exemple, un item peut appartenir à quelqu'un ou être stocké dans un "stockage".
Dans le second cas, tu vas gérer l'accès au stockage selon le personnage et pas la propriété de l'item. Tu pourras ainsi définir un coffre en banque, un inventaire du personnage. Toute opération sur la propriété de l'item ne sera que le transfert d'un lieu de stockage à un autre. Pour équiper un casque, il peut suffire de définir la tête de personnage comme un lieu de stockage. Il apparait alors qu'un lieu de stockage peut être limité en quantité voir en type d'item.

Pour les objets Il vaut mieux se rapprocher du réel. Un type d'object (epée, voiture...), un modèle d'objet (Mégane,Golf...), une version (GTI,TX..) et enfin la vrai voiture. On voit bien en général l'épée que le personnage à dans les mains, mais il est relativement difficile de répartir les données entre les tables. Doit on garder toutes les versions possible dans une table de référence et dire que l'item "réel" correspond à tel version ? Ou doit on avoir une table de toutes les items ?

[quote="olivierg"]en fait je me rend compte que.. cette table va être colossale en terme d'enregistrements.

ya intérêt à bien gérer les indexes & compagnie..
[/quote]

Effectivement, surement la plus "grosse" en termes de nombre de tuple.

coté indexation ce n'est pas forcément un gros soucis, sachant les recherches portent essentiellement sur les clefs primaire et qu'elles sont déjà indexées par nature (une pk c'est indexée na :) ).

Coté bouquin j'en connais pas trop, perso j'ai acheté le livre [url=http://sqlpro.developpez.com/booksql05/]SQL (collection syntex)[/url] de [url=http://sqlpro.developpez.com/]Frédéric Brouard (SQLpro )[/url].

Coté modélisation quelque chose sur merise, mais pas toute la méthode, généralement on utilise que le modèle entité association (qui est une petite partie de la méthode merise).

Tu peux aussi te renseigner sur la démarche suivis pas Craig Lerman sur la modélisation d'une application (avec UML). mais la pour le coup je ne connais pas trop d'ouvrage.


@+

ahhh merci j'avais pas vu, je comprend bcp mieux à présent, ça me trottait :)

en fait je me rend compte que.. cette table va être colossale en terme d'enregistrements.

ya intérêt à bien gérer les indexes & compagnie..

quoi qu'il en soit, merci pour ton aide c'est bien plus clair.

je pense malgré tout que je vais acheter un bouquin sur le design de bases, en auriez-vous à conseiller par hasard ? (pas forcément sur uml/merise mais un livre plus générique qui traite du design, j'imagine qu'il aborderais ces méthodes dans tous les cas).

CREATE TABLE statItem(
[size=150] [b] valeur Int (25), -- la :)[/b][/size]
idItems_items AUTO_INCREMENT (25),
idStat_stats AUTO_INCREMENT (25),
PRIMARY KEY (idItems_items,idStat_stats)
)ENGINE=InnoDB;

cette table contient l'id de l'item, l'id de la stat et sa valeur.

ça permet de tout maitriser, sinon il faudrait que tu ai une stat +2 bourrinage, une + 48 bourrinnage etc etc.

@+

oui j'ai bien compris cette partie là, sans soucis :)

ce que je ne comprend pas, c'est ou tu stocke les valeurs des items :) (les stats elles même, le +15, +38, +2 etc. listés au dessus)

merci!

[quote="olivierg"]mais cette perspective m’embête car si on décide de rajouter une nouvelle stat du jour au lendemain (exemple : vitesse d'attaque), il faut rajouter une colonne sur tous les items de la base.[/quote]

C'est justement à ça que sert ce système :)


tu n'est pas obligé de mettre toute les stats as tout les items.

donc les données pourrait êtres
[quote]
IDItems_items IDStat_stats
1 1
1 2
2 3
2 2
3 1
3 4
3 3
4 1
4 3
etc etc
[/quote]

Donc si tu ajoute une stat c'est pas un problème :)

Lorsque tu fera ta jointure tu n'aura que ce que tu as prévue c'est tout.

(select ... from items join stat using(idItem))


Je sais pas si mon explication est très clair, plus simple c'est que tu test et que tu te fasse une interface simple tu devrais mieux comprendre :)


@+

Ah, une dernière chose (excuse moi je vais t'embêter) mais toujours dans l'optique des stats, il y a quelque-chose que j'ai du mal à comprendre pour le stockage des stats des items par exemple.

si je prend ton example avec ces 3 tables :

[code]
DROP TABLE IF EXISTS statItem;
CREATE TABLE statItem(
valeur Int (25),
idItems_items AUTO_INCREMENT (25),
idStat_stats AUTO_INCREMENT (25),
PRIMARY KEY (idItems_items,idStat_stats)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS stats;
CREATE TABLE stats(
idStat AUTO_INCREMENT (25),
nomStat Varchar (25),
description Varchar (150),
PRIMARY KEY (idStat)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS items;
CREATE TABLE items(
idItems AUTO_INCREMENT (25),
nomItem Varchar (50),
idQualite_qualite AUTO_INCREMENT (25),
PRIMARY KEY (idItems)
)ENGINE=InnoDB;
[/code]


ça donnerait un truc du genre :

[code]
ITEMS EXAMPLE

idItem nomItem

1 item_qui_rox
2 item_qui_sux
3 item_random
[/code]

[code]
STATS EXAMPLE

idStat nomStat description

1 intelligence dégats magiques
2 force dégâts physiques
3 vitalité points de vie
4 dextérité esquive et dégâts d'archerie
[/code]

[code]
STATITEM EXAMPLE


IDItems_items IDStat_stats

1 1
1 2
1 3
1 4
[/code]

mais soit je vois mal le truc, soit c'est pas vraiment ce que je cherche :)

en fait, chaque item a des stats particulières, par exemple :

item_qui_rox pourrait donner :

intelligence +15
force +15
vitalité +50
dextérité +10

et item_qui_sux pourrait donner :

intelligence +15
vitalité +2

item_random pourrait donner :

force +5
vitalité +78
dextérité +0

comment puis-je gérer ça justement ? (en fait depuis le départ c'est sourtout ça qui me tracasse :p tu les met ou les stats ?! les valeurs du moins)

pour les stats du perso, je pense que j'aurais pas trop de mal, car je vais gérer ça in-game (suivant l'équipment que le perso va porter, j'additionne les stats à la volée dans le code, et je met ça en mémoire/session/etc.. bref, ça reste à voir), mais pour les stats d'items, c'est plus embêtant (d'ou mon idée de départ ou je voulais faire des champs pour chaque item avec bonus_intel, bonus_force, bonus_machin etc.. dans chaque item).

mais cette perspective m'embete car si on décide de rajouter une nouvelle stat du jour au lendemain (exemple : vitesse d'attaque), il faut rajouter une colonne sur tous les items de la base.

merci de tès lumières encore et de passer du temps à rédiger tout cela :)

cdt

merci pour ta réponse aussi rapide, je comprend mieux.

commes le entités ressemblent fortement aux tables du mcd, je pensais que l'on devait spécifier également toutes les colonnes et clefs (et donc clefs étrangères etc) dans le schéma Merise directement, donc je ne comprenais pas trop, pour moi il manquait des infos :)

merci bcp c'est plus clair une fois encore !

je vais regarder le code SQL voir si ça correspond et si ça me permet de mieux comprendre

cdt,

DROP TABLE IF EXISTS membres;
CREATE TABLE membres(
        idMembre     Auto_increment (25),
        nom     Varchar (25),
        email     Varchar (255),
        passwd     Varchar (256),
        PRIMARY KEY (idMembre)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS personnages;
CREATE TABLE personnages(
        idPerso     Auto_increment (25),
        pseudo     Varchar (25),
        idMembre_membres     Auto_increment (25),
        idRace_races     Auto_increment (25),
        idRace_classes     Auto_increment (25),
        PRIMARY KEY (idPerso)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS races;
CREATE TABLE races(
        idRace     Auto_increment (25),
        nomRace     Varchar (25),
        description     Varchar (500),
        PRIMARY KEY (idRace)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS items;
CREATE TABLE items(
        idItems     Auto_increment (25),
        nomItem     Varchar (50),
        idQualite_qualite     Auto_increment (25),
        PRIMARY KEY (idItems)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS stats;
CREATE TABLE stats(
        idStat     Auto_increment (25),
        nomStat     Varchar (25),
        description     Varchar (150),
        PRIMARY KEY (idStat)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS mobs;
CREATE TABLE mobs(
        idMob     Auto_increment (25),
        nomMob     Varchar (25),
        idRace_races     Auto_increment (25),
        idRace_classes     Auto_increment (25),
        PRIMARY KEY (idMob)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS classes;
CREATE TABLE classes(
        idRace     Auto_increment (25),
        nomRace     Varchar (25),
        description     Varchar (150),
        PRIMARY KEY (idRace)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS sacs;
CREATE TABLE sacs(
        idSAc     Auto_increment (25),
        numeroSac     Int (2),
        nbSlot     Int (2),
        idPerso_personnages     Auto_increment (25),
        idItems_items     Auto_increment (25),
        PRIMARY KEY (idSAc)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS qualite;
CREATE TABLE qualite(
        idQualite     Auto_increment (25),
        nom     Varchar (25),
        PRIMARY KEY (idQualite)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS statItem;
CREATE TABLE statItem(
        valeur     Int (25),
        idItems_items     Auto_increment (25),
        idStat_stats     Auto_increment (25),
        PRIMARY KEY (idItems_items,idStat_stats)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS itemsPorté;
CREATE TABLE itemsPorté(
        idPerso_personnages     Auto_increment (25),
        idItems_items     Auto_increment (25),
        PRIMARY KEY (idPerso_personnages,idItems_items)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS statMob;
CREATE TABLE statMob(
        valeur     Int (25),
        idMob_mobs     Auto_increment (25),
        idStat_stats     Auto_increment (25),
        PRIMARY KEY (idMob_mobs,idStat_stats)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS itemMob;
CREATE TABLE itemMob(
        idItems_items     Auto_increment (25),
        idMob_mobs     Auto_increment (25),
        PRIMARY KEY (idItems_items,idMob_mobs)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS statPerso;
CREATE TABLE statPerso(
        valeur     Int (25),
        idPerso_personnages     Auto_increment (25),
        idStat_stats     Auto_increment (25),
        PRIMARY KEY (idPerso_personnages,idStat_stats)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS contient;
CREATE TABLE contient(
        idSAc_sacs     Auto_increment (25),
        idItems_items     Auto_increment (25),
        PRIMARY KEY (idSAc_sacs,idItems_items)
)ENGINE=InnoDB;

ALTER TABLE personnages ADD CONSTRAINT FK_personnages_idMembre_membres FOREIGN KEY (idMembre_membres) REFERENCES membres(idMembre)
ALTER TABLE personnages ADD CONSTRAINT FK_personnages_idRace_races FOREIGN KEY (idRace_races) REFERENCES races(idRace)
ALTER TABLE personnages ADD CONSTRAINT FK_personnages_idRace_classes FOREIGN KEY (idRace_classes) REFERENCES classes(idRace)
ALTER TABLE items ADD CONSTRAINT FK_items_idQualite_qualite FOREIGN KEY (idQualite_qualite) REFERENCES qualite(idQualite)
ALTER TABLE mobs ADD CONSTRAINT FK_mobs_idRace_races FOREIGN KEY (idRace_races) REFERENCES races(idRace)
ALTER TABLE mobs ADD CONSTRAINT FK_mobs_idRace_classes FOREIGN KEY (idRace_classes) REFERENCES classes(idRace)
ALTER TABLE sacs ADD CONSTRAINT FK_sacs_idPerso_personnages FOREIGN KEY (idPerso_personnages) REFERENCES personnages(idPerso)
ALTER TABLE sacs ADD CONSTRAINT FK_sacs_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE statItem ADD CONSTRAINT FK_statItem_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE statItem ADD CONSTRAINT FK_statItem_idStat_stats FOREIGN KEY (idStat_stats) REFERENCES stats(idStat)
ALTER TABLE itemsPorté ADD CONSTRAINT FK_itemsPorté_idPerso_personnages FOREIGN KEY (idPerso_personnages) REFERENCES personnages(idPerso)
ALTER TABLE itemsPorté ADD CONSTRAINT FK_itemsPorté_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE statMob ADD CONSTRAINT FK_statMob_idMob_mobs FOREIGN KEY (idMob_mobs) REFERENCES mobs(idMob)
ALTER TABLE statMob ADD CONSTRAINT FK_statMob_idStat_stats FOREIGN KEY (idStat_stats) REFERENCES stats(idStat)
ALTER TABLE itemMob ADD CONSTRAINT FK_itemMob_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE itemMob ADD CONSTRAINT FK_itemMob_idMob_mobs FOREIGN KEY (idMob_mobs) REFERENCES mobs(idMob)
ALTER TABLE statPerso ADD CONSTRAINT FK_statPerso_idPerso_personnages FOREIGN KEY (idPerso_personnages) REFERENCES personnages(idPerso)
ALTER TABLE statPerso ADD CONSTRAINT FK_statPerso_idStat_stats FOREIGN KEY (idStat_stats) REFERENCES stats(idStat)
ALTER TABLE contient ADD CONSTRAINT FK_contient_idSAc_sacs FOREIGN KEY (idSAc_sacs) REFERENCES sacs(idSAc)
ALTER TABLE contient ADD CONSTRAINT FK_contient_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)

de rien :)


ce que tu ne comprend pas est ce qu'il te manque pour lire le sshéma :)

ce qu'il faut comprendre dans ce schéma c'est que l'on parle d'entité (les tables c'est plus tard).
Qu'est ce qu'une entité, c'est la représentation de quelque chose de "réel" par exemple un personnage est une entité. le modèle entité relation (de la méthode merise) représente donc les relations entre les entités (qui sont nommées au mieux avec des verbes, créer, appartient etc etc, c'est pas toujours facile comme mon schéma l'indique :) ).

Ensuite viens le passage du modèle aux tables.
Tu as remarqué qu'il n'y avait pas de référence aux autres tables dans le schéma, normal elle ne définissent pas l'entité, et sont indiqué par les relations.
Les règles de passage sont indiquées dans des cours ;)

Par exemple sur développez.com il y a une section merise.

en fait les relations que tu vois ne sont pas forcément de simple clef étrangère, il peux s'agit de table.
C'est cas lors d'une relation n - n par exemple.

dans le cas de la relation peso / stat il s'agit de fournir des stats à des personnages. sachant qu'un personnagepeux avoir une pour plusieur stats (1,n) et qu'une stat peux être utilisée par zéro ou n perso (0,n).

la relation "globale" c'est n, n. cette relation sera traduite par une table très simple (idperso,idStat) (avec les deux champs en clef primaire).
maintenant dans la relation j'ai ajouté une valeur (histoire que la stat puisse changer, par exemple quand tu prend un niveau. la table devient donc (idperso,idStat, valeur), la clef primaire est toujours le couple (idperso,idStat) .

c'est la même chose pour les stats des mobs ou des items :)

pour ce qui est des sac, c'est pareil un personnage peux avoir de 1 à n sac et un sac peux contenir de zéro à n items.
Dans le schéma on pourrait ajouter, dans l'entité sac, le nombre d'élément max que le sac peux contenir (pratique ;) ).
donc au final il y aura un table sacs avec (idSac, numéro, idPerso)
par contre la relation contient va être une table (idSac,idItem).

j'ai fait simple, tu peux avoir une table avecdes sac type (qui au final ne seront que des items avec un stat nbslot par exemple) dans ce cas ta table sacs aura deux relatio avec items
une relation pour le type de sac et une pour la contenance.
La première se traduit par une clef étrangère dans la tables sac et la second toujours pas une table (idSac,idItems).



J'espère être clair, mais je ne suis pas certain :)

pour le schéma j'ai utilisé JMesire, fait en java, il est gratuit, assez limité mais fait ce dont on a besoin a la base : le MCD (et le vérifie), leMPD et le passage vers le code SQL. Limité à mysql mais il fait du code relativement portable pas trop complexe à modifier.

Il ne fait pas toujours des trucs qui me plaise (mais vont dans le sens de ce que disait Nagol sur le dénomination des clef primaire :)

sinon le meilleur que j'ai pu tester (pour moi) c'est power AMC (de sybase) par contre pas gratis, mais tu peux tester 15J si tu veux regarder la chose.

par exemple il donne le script suivant (dans lequel j'ai ajouté le type de sac et nombre de slot dans le sac).
Je ne l'ai pas vérifier, c'est qu'un exemple :)
[sql]
DROP TABLE IF EXISTS membres;
CREATE TABLE membres(
idMembre Auto_increment (25),
nom Varchar (25),
email Varchar (255),
passwd Varchar (256),
PRIMARY KEY (idMembre)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS personnages;
CREATE TABLE personnages(
idPerso Auto_increment (25),
pseudo Varchar (25),
idMembre_membres Auto_increment (25),
idRace_races Auto_increment (25),
idRace_classes Auto_increment (25),
PRIMARY KEY (idPerso)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS races;
CREATE TABLE races(
idRace Auto_increment (25),
nomRace Varchar (25),
description Varchar (500),
PRIMARY KEY (idRace)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS items;
CREATE TABLE items(
idItems Auto_increment (25),
nomItem Varchar (50),
idQualite_qualite Auto_increment (25),
PRIMARY KEY (idItems)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS stats;
CREATE TABLE stats(
idStat Auto_increment (25),
nomStat Varchar (25),
description Varchar (150),
PRIMARY KEY (idStat)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS mobs;
CREATE TABLE mobs(
idMob Auto_increment (25),
nomMob Varchar (25),
idRace_races Auto_increment (25),
idRace_classes Auto_increment (25),
PRIMARY KEY (idMob)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS classes;
CREATE TABLE classes(
idRace Auto_increment (25),
nomRace Varchar (25),
description Varchar (150),
PRIMARY KEY (idRace)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS sacs;
CREATE TABLE sacs(
idSAc Auto_increment (25),
numeroSac Int (2),
nbSlot Int (2),
idPerso_personnages Auto_increment (25),
idItems_items Auto_increment (25),
PRIMARY KEY (idSAc)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS qualite;
CREATE TABLE qualite(
idQualite Auto_increment (25),
nom Varchar (25),
PRIMARY KEY (idQualite)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS statItem;
CREATE TABLE statItem(
valeur Int (25),
idItems_items Auto_increment (25),
idStat_stats Auto_increment (25),
PRIMARY KEY (idItems_items,idStat_stats)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS itemsPorté;
CREATE TABLE itemsPorté(
idPerso_personnages Auto_increment (25),
idItems_items Auto_increment (25),
PRIMARY KEY (idPerso_personnages,idItems_items)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS statMob;
CREATE TABLE statMob(
valeur Int (25),
idMob_mobs Auto_increment (25),
idStat_stats Auto_increment (25),
PRIMARY KEY (idMob_mobs,idStat_stats)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS itemMob;
CREATE TABLE itemMob(
idItems_items Auto_increment (25),
idMob_mobs Auto_increment (25),
PRIMARY KEY (idItems_items,idMob_mobs)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS statPerso;
CREATE TABLE statPerso(
valeur Int (25),
idPerso_personnages Auto_increment (25),
idStat_stats Auto_increment (25),
PRIMARY KEY (idPerso_personnages,idStat_stats)
)ENGINE=InnoDB;

DROP TABLE IF EXISTS contient;
CREATE TABLE contient(
idSAc_sacs Auto_increment (25),
idItems_items Auto_increment (25),
PRIMARY KEY (idSAc_sacs,idItems_items)
)ENGINE=InnoDB;

ALTER TABLE personnages ADD CONSTRAINT FK_personnages_idMembre_membres FOREIGN KEY (idMembre_membres) REFERENCES membres(idMembre)
ALTER TABLE personnages ADD CONSTRAINT FK_personnages_idRace_races FOREIGN KEY (idRace_races) REFERENCES races(idRace)
ALTER TABLE personnages ADD CONSTRAINT FK_personnages_idRace_classes FOREIGN KEY (idRace_classes) REFERENCES classes(idRace)
ALTER TABLE items ADD CONSTRAINT FK_items_idQualite_qualite FOREIGN KEY (idQualite_qualite) REFERENCES qualite(idQualite)
ALTER TABLE mobs ADD CONSTRAINT FK_mobs_idRace_races FOREIGN KEY (idRace_races) REFERENCES races(idRace)
ALTER TABLE mobs ADD CONSTRAINT FK_mobs_idRace_classes FOREIGN KEY (idRace_classes) REFERENCES classes(idRace)
ALTER TABLE sacs ADD CONSTRAINT FK_sacs_idPerso_personnages FOREIGN KEY (idPerso_personnages) REFERENCES personnages(idPerso)
ALTER TABLE sacs ADD CONSTRAINT FK_sacs_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE statItem ADD CONSTRAINT FK_statItem_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE statItem ADD CONSTRAINT FK_statItem_idStat_stats FOREIGN KEY (idStat_stats) REFERENCES stats(idStat)
ALTER TABLE itemsPorté ADD CONSTRAINT FK_itemsPorté_idPerso_personnages FOREIGN KEY (idPerso_personnages) REFERENCES personnages(idPerso)
ALTER TABLE itemsPorté ADD CONSTRAINT FK_itemsPorté_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE statMob ADD CONSTRAINT FK_statMob_idMob_mobs FOREIGN KEY (idMob_mobs) REFERENCES mobs(idMob)
ALTER TABLE statMob ADD CONSTRAINT FK_statMob_idStat_stats FOREIGN KEY (idStat_stats) REFERENCES stats(idStat)
ALTER TABLE itemMob ADD CONSTRAINT FK_itemMob_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
ALTER TABLE itemMob ADD CONSTRAINT FK_itemMob_idMob_mobs FOREIGN KEY (idMob_mobs) REFERENCES mobs(idMob)
ALTER TABLE statPerso ADD CONSTRAINT FK_statPerso_idPerso_personnages FOREIGN KEY (idPerso_personnages) REFERENCES personnages(idPerso)
ALTER TABLE statPerso ADD CONSTRAINT FK_statPerso_idStat_stats FOREIGN KEY (idStat_stats) REFERENCES stats(idStat)
ALTER TABLE contient ADD CONSTRAINT FK_contient_idSAc_sacs FOREIGN KEY (idSAc_sacs) REFERENCES sacs(idSAc)
ALTER TABLE contient ADD CONSTRAINT FK_contient_idItems_items FOREIGN KEY (idItems_items) REFERENCES items(idItems)
[/sql]

@+

Salut,

Merci à vous pour vos réponses, et merci pour l'exemple concret moogli c'est sympa, je comprend bcp mieux.
je n'ai pas la connnaissance UML/Merise requise pour tout lire proprement peut-être (je vais aller lire quelque docs dessus..), mais malgré ton schéma, j'ai du mal à comprendre comment tu gère concrètement l'association par exemple des stats des personnages ?

sur ton ER je vois deux tables par exemple (personnages & stats), mais aucune clef en commun ?
ton lien "statperso" doit se gérer à l'aide d'une table de relation également ? (ou même plusieurs)

en tout cas ton schéma est très clair et très logique, c'est pratique d'avoir cette vue modélisée (tu modélise avec un programme particulier ?), j'étais habitué à modéliser des petits MCD de base, mais n'ai jamais pensé à le faire en UML/Merise, ne connaissant pas la technique, c'est très intéressant.

mais si ce n'est pas trop demander, pourrais-tu m'éclairer simplement en me donnant un exemple de cette relation personnage/stats (ou mobs/stats par exemple).

après, pour les relations du type sac -> items, tu fais une relation de base ? par exemple dans la table 'items', on crée une colnone idSAc ? et on s'occupe de la relation manuellement ? (ex : WHERE items.idSAc = sacs.idSAc ?)

merci encore

cdt,