Hello,
je modélise une base avec powerdesigner là, et je me trouve dans un cas que je n'avais jamais eu avant, et je ne sais pas comment le modéliser.
J'ai une entité Joueurs, chaque joueur comporte entre autre 8 compétences. La valeur de ces 8 compétences est choisie parmi la même plage de valeur, et c'est là que je ne sais pas comment faire et quelle relation mettre entre ma table Joueurs et la table contenant les paires de clef-libellé dont chacune des 8 caracts d'un joueur doit faire partie.
 
Si qqun a une idée

Dernier up avant fermeture définitive

je ne pige pas trop ce que tu recherche....tu veux savoir si il existe une contrainte qui te permettrait de fixer une valeur min et max de ton champ ?
Si c le cas, traite ca directement dans ton prog ca sera + simple je pense...

bon tu as bien une contrainte "CHECK" qui te permet de controler la valeur, mais je ne sais pas si ca s applique a toute bdd, et si niveau perf ce que ca donne..;

Ok je réexplique : 6 champs de ma table joueur sont des niveaux disons en forme, endurance etc...
Les valeurs possibles de ces 6 champs sont les mêmes.
Il n'y aurait eu qu'un champ c'était facile, suffit de faire une relation 1,1------0,n et hop. Mais comment faire ça pour 6 champs ?  
Sinon un CHECK ça ferait CHECK IN (nom de la table) ?

ok tu n tjs pas tres explicite car j avais compris que tu voulais renseigner des vertues dans une table joueur, par ex des vertues allant de 0 a 20
 
donc a priori moi j essayerai d appliquer SI tu veux reellement mettre une contraite d integrite (je trouve que c se casser le Q pour pas grand chose, car autant mettre un controle sur un champ qui aurait pour valeur min 0 et max 20) :
 
CREATE TABLE Joueur(
 
idJoueur integer PRIMARY KEY,
Nom varchar(10) NOT NULL,
Force integer, CHECK (Force > 0 AND Force < 20),
Sagesse integer, CHECK (Sagesse > 0 AND Sagesse < 20),
...
)
 
Syntaxe exacte a verifier

C'est une plage de valeurs (p.e. de 0 à 20), ou un ensemble fini (p.e. faible, moyen, bon, excellent) ?

Ensemble fini
C'est bien là le problème, c'est compliqué à expliquer en plus (en fait c'est encore plus compliqué que ça mais déja j'aimerai résoudre ça d'abord)
Je précise que je n'en suis qu'au MCD, évidemment je pourrais résoudre le problème par programmation ou check mais ça m'étonne que Merise (et powerAMC) n'ait rien prévu pour ce genre de cas.
 
J'essaie de reformuler donc :
6 champs de ma table joueurs font donc partie d'un ensemble fini (de catastrophique à divin disons, avec 20 palliers)
Quand on a juste un champ dans un cas comme ça, on fait une table "NIVEAUX" avec les 20 enregistrements IDniveau et libelNiveau, on fait une relation et au final dans le MPD on se retrouve avec une clef étrangère IDniveau dans la table "JOUEURS". Le problème là c'est que j'ai 6 champs à faire avec les mêmes niveaux, je vais donc pas faire 6 tables "NIVEAUXx"...
Bref je suis coincé là dessus, je sais pas comment modéliser ça..

ben donc tu as 6 champs a linker sur ta table niveau, vu qu elle est fixe cela ne pose en aucun cas un pb...
 
Tu as donc 6 cles etrangeres pour chaque vertue definie sur niveau ou alors g encore manque un episode qqpart

Ah ben nan t'as rien raté, jsais pas pourquoi j'ai pas pensé à faire juste ça
Merci beaucoup à vous tous

Eventuellement comme le propose Mkracing66, mais avec l'inconvénient que si le nombre de caractéristiques des joueurs peut s'étendre, tu te retrouves avec un grand nombre de FK vers la table niveau, ce qui ne permet pas de traitement croisé.
 
Mieux vaut alors Joueur 1--n Caracteristique n--1 Niveau.
 
Plus flexible et plus générique.

Si tu ne fais que de la modelisation, je ne ferais pas une table SI elle est fixe...je trouve ca lourd a souhait
 
Meme remarque / a la modelisation de sircam en tenant compte du contexte du RPG, car niveau modelisation ok c tout beau tout propre mais des que tu code ca ca devient ingerable pour pas grand chose, caracteristique sera tjs lie au joueur, tu devras te taper des jointures a chaque fois ouch

Ben Sircam si je fais comme tu dis jvais avoir mass requète juste pour afficher un joueur c'est pas très performant comme soluce jpense.  
Mkracing66 : tu ferais quoi donc si tu ne fais pas de table ?

C'est une balance à faire.
 
Si tu es persuadé que le nombre de caractéristiques est limité à 6, de manière immuable, tu peux garder la solution que tu proposes.
 
Mais déjà là, ce n'est pas très souple. P.e. je veux afficher tous les domaines pour lequels tel joueur est bon ou plus. Tu vas déjà devoir besogneusement tester chacun des 6 champs.
 
A l'inverse, le modèle que je propose demandera de cogiter plus sur les queries, mais on aime ça, n'est-ce pas ?
 
PAR CONTRE, si les caractéristiques peuvent potentiellement s'élargir, la lourdeur du choix avec un FK par champs se fera d'autant plus sentir, alors que le surcoût sera nul pour la solution à 3 tables.
 
Il n'y a pas de solution unique, et la facilité immédiate guide bien souvent nos choix. Question de trade-off.

Glod2 , si tu veux qu on donne reellement une opinion objective faut nous en expliquer un peu plus
 
Ton projet se limite t il juste a la modelisation, tu compte developper ca par la suite ? si oui, sur quelle bdd tu compte appliquer cela ? bref il n existe pas une reponse toute faite pour un tel cas

Non jvais le developper
Sur Firebird certainement pour le SGBD.
Enfin là c'est bon j'ai tout ce qu'il me faut, jpeux passer à la question suivante
Ces fameux niveaux qu'on a fait, en fait ce sera pas des entiers.
Tous les niveaux auront des décimales, et je suis de nouveau bloqué, je sais pas comment faire dans ma table niveau pour faire en sorte que par exemple le niveau catastrophique ne soit pas 0 mais un intervalle entre 0 et 0.99 . Je sais mais pas si c'est possible en MCD en fait ça.

tu veux donc 20 elements qui represente ton niveau par vertue, et chaque element represente en fait un intervalle de N a N.99
 
T sur que tu t emmerde pas pour rien serieux ?  
 
regle simple : "plus tu fais simple mieux c est"
 
Tout a l heure, sircam avait raison niveau modelisation et encore, mais derriere dans son appli il se serait tape des requetes de tares avec multi jointures juste pour des elements qui se ressemblent tous.
Les requetes sont deja assez complexes a simplifier et optimiser, faut pas en rajouter trop
Faire generique oui, mais pas trop non plus
 
 
Honnetement perso je n aime guere les "categories" de niveau que tu veux faire dans ton RPG, perso je mettrais une valeur float entre 0 et 20, et dans mon appli je fais une equivalence par bornes (de 0 a 0.99 => gros noob, 1 a 1.99 = noob , 19 a 19.99 => roxxor) et basta
 
 
[Edit] tu auras deja assez de trucs a modeliser pour les classes de monstres, lieux, objets et autres, avec du multi heritage parfois, plus une etude des fonctions heuristiques si tu veux faire une IA donc t embete pas trop sur les details

Oui c'est ske je vais être obligé de faire jcrois
Pour le jeu c'est un jeu web, pas vraiment un rpg, ces joueurs seront des joueurs d'une équipe de foot-bourrin
Donc chaque équipe aura une 20aine de ces joueurs. (ou plus ou moins selon ce qu'il achète)
Je fais ça juste pour le fun de le faire y a pas de but commercial ou autre, tfaçon jfais ça en jsp / servlets donc bon pour trouver un hébergeur gratos autre quoi moi même

Dans ce cas-ci, je plussoie : te casses pas la tête, tu n'y gagneras rien, il n'y a pas de trad-off en jeu.
 
Toutes les contraintes fonctionnelles ne doivent pas forcément se traduire au niveau de la DB (il y a deux écoles là-dessus). D'ailleurs, il n'est pas toujours possible de formaliser une telle contrainte au niveau de la DB (p.e. MySQL est assez limité).
 
De toute façon, il n'est pas très bon d'utiliser l'intervalle ]0;1[ (ouvert ou fermé), pour des raisons d'arrondis - un 0.1 risque de devenir 0.100...1 ou 0.9999...
 
=> Te prends pas la tête.

Hop j'ai de nouveau besoin de votre aide.
Dans ma base j'ai entre autres, 3 tables : JOUEURS,MATCHS et EQUIPE. Une équipe fait jouer des matchs à ses joueurs.
Donc au départ j'ai fait un lien entre équipes, match et joueur ce qui au final me donnera une table contenant idjoueur,idmatch et idequipe. Le blem c'est que ce sera pas forcément très perf pour afficher un match, du coup jme demande ske je pourrais faire de mieux que ça niveau perf, même si c'est un peu moins "merise".

????
 
ou est le pb niveau perf ? et ou est le pb niveau merise ?

niveau conceptuel <> niveau physique
Au niveau physique, on s'en fout que ce soit "Merise". Le principal est que cela aille vite (tout en restant correct évidemment)...

et ?
 
je ne vois tjs pas ou le pb se trouve concernant un affichage des matchs
 
Sa structure reste assez basique je trouve, 3 tables liees, une utilisation de chaque table de facon independante ou presque...

ben là mon truc il est correct.
Par contre pour les "lineup" de chaque match seront éparpillés dans une 30 aines d'enregistrements, ce serait pas mieux de faire style une table LINEUP justement contenant pour un match et une équipe, tous les joueurs ayant joué ?
Parce que la table croisée match/joueurs/equipes elle va vite gonfler et faire des milliers d'enregistrements

oui je sais bien c'est exactement ske je dis, et c'est pour ça que je demande si ce serait pas mieux de trouver une solution autre.

ha ben tu n as jamais parle des lines up par match....tu as parle d afficher la liste des matchs
 
Faudrait que tu sois plus precis sur ce que tu cherche reellement a faire, un descriptif un peu plus etoffe des tables car pour le moment on ne peut que faire des suppositions.
Firebird O_o , c un choix plutot etrange je trouve, et concernant les tables matchs et equipes t pas pret d atteindre le millier d enregistrement pour le moment donc niveau perf ca devrait aller...Mais line up ca devrait etre plus galere a faire, surtout avec une vingtaine de joueurs, je sents que ca va etre lourd
 

Pourquoi Firebird un choix étrange
 
Sinon, ben si la table qui fait la jointure équipe/joueur/match va faire 32 enregistrements par matchs en l'état actuel des choses (11 joueurs + 5 remplaçants * 2 équipes ) avec juste 10 équipes et 2 matchs/semaine on est déja à 640 enregistrements.
Pour la table lineup, elle remplacerait la jointure entre joueur/equipe/match (jointure qui me permet de récupérer tous les joueurs ayant joué pour telle équipe pour tel match) qui donne donc une table comme :
a_joué(idmatch,idequipe,idjoueur)
 
Je supprimerai donc cette jointure et je créerai une table
lineup(idmatch,idequipe,idjoueur1,idjoueur2......,idjoueur15)

oula confond pas enregistrements et champs enregistres
 
10 equipes avec 2 matchs/semaines ca fait 2*5 matchs donc 10 enregistrements de matchs, par contre pour chaque match tu enregistre bien 32 champs indiquant quels sont les joueurs affectes mais t imagine la jointure de malade que ca serait ?

euh ben jconfonds pas là oO
Et en parlant de la jointure de malade, c'est exactement ske je demande. Donc apparament c'est mieux de faire une table à la place.

je ne mettrais que le nom du joueur dans la table lineup comme ca tu affiche directement son nom, par contre si tu as besoin de voir le details de ses caracteristiques tu n aurais qu un select * from joueurs where nom=mon_joueur
 
Si tu mets les id, au moment d afficher les lines up vu que tu n affichera pas l id tu vas te taper une requete avec une jointure sur 33 tables dont 32 fois la meme (1 line up + 32 fois joueurs).
 
Par contre, niveau nombre d enregistrements, pour moi un enregistrement dans la table c une ligne complete, qu il y ait 3 champs ou 25 donc
 
10 equipes = 160 joueurs , 2 matchs / semaines donc 10 matchs possibles par semaines, ca reste pour le moment negligeable
 
A moins que je delire totalement ce matin, ce qui n pas exclu