+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Besoin d'avis pour un problème de table (/showthread.php?tid=2202)
Pages :
1
2
RE: Besoin d'avis pour un problème de table - naholyr - 30-12-2007
C'est tout à ton honneur d'avoir défendu ainsi ton système.
Je trouve en effet qu'il a ses bons côtés, ce sera vraiment un jeu de tactique et de gestion d'alliances pour le coup.
Je vois que tu as défini les 4 tables nécessaires, mais la diplomatie des alliances ne va-t-elle pas être gérée de la même manière ? Un joueur peut être ennemi d'une alliance, ou c'est seulement alliance-alliance ?
Si c'est alliance-alliance + alliance-joueur + alliance-territoire ça t'en ajoute 5 de plus, et dans ce cas peut-être faudrait-il passer à un système générique à 5 champs (typeA, idA, typeB, idB, statutAB). L'avantage d'un tel système c'est la "compactisation" du système (et la possibilité d'ajouter de nouvelles interactions sans ajouter de nouvelles tables), en revanche le schéma n'est plus normé : il n'a plus de représentation sous forme de relation (une clé étrangère "générique" relative à plusieurs tables, je ne crois pas que ça existe formellement) et n'assure plus seul la cohérence des données.
RE: Besoin d'avis pour un problème de table - alfanor - 30-12-2007
Oui j'y pense sérieusement à faire de cette façons (comme je fais d'habitude quoi ^^), car entre les membres, leurs territoires, leurs armées et les alliances ça fait pas mal de tables qui à l'arrivée sont toutes les mêmes, donc au lieu de me trimballer une dizaine de tables quasi identique, une seul et même ce serait plus simple pour l'organisation.
RE: Besoin d'avis pour un problème de table - Mysterarts - 30-12-2007
Oxman, je suis pas sur que tu fasses attention à ma remarque, mais je te demande de cesser (encore une fois), ton agressivité qui manque de plus d'argumentation...
Je suis d'accord avec Naholyr, ton système original est tout a fait défendable
Bonne chance pour organiser tout ca ^^
Mysterarts
RE: Besoin d'avis pour un problème de table - Mysterarts - 30-12-2007
Ma remarque ne portait pas sur ton dernier message, mais les deux précédents.
Tu peux exprimer une opinion, avertir qqu, aider qqu, et même avoir raison sans pour autant parler aussi mal aux gens...
Mysterarts, désespérant de devoir dire ce genre de choses, ça devrait être logique...
RE: Besoin d'avis pour un problème de table - naholyr - 30-12-2007
oxman, son système est pourtant bien réaliste comme il l'a indiqué : une guerre est rarement totale.
Au sein d'une guerre entre deux nations, il y peut exister de multiples raisons pour qu'il y ait des zones sans conflit (rébellion de l'état-major local, intérêts communs sur cette zone, présence tierce imposant une alliance locale, etc...). De même au sein d'une alliance, il peut exister des divergences locales pouvant mener au conflit.
En regardant les guerres non médiatisées (comme celles qui se déroulent en Afrique par exemple) on trouve pas mal d'exemples de ce genre de "petits arrangements locaux".
Sinon pour revenir au sujet de l'organisation des tables : avoir 38 tables qui se ressemblent beaucoup n'est pas forcément une tare, mais c'est vrai que ça rend la gestion plus difficile lorsqu'on n'a pas prévu d'interface dédiée.
Comme je te l'ai dit, l'inconvénient d'une table avec des champs génériques, c'est qu'on ne peut pas assurer la cohérence des données simplement en se portant au schéma, on ne peut même plus représenter les relations
Une autre solution avec une seule table (qui ne permet toujours pas d'assurer la cohérence des données, mais qui permet de sortir un graphique sensé) :
une table "statut" (joueurA, territoireA, allianceA, joueurB, territoireB, allianceB, statut), la règle étant que un seul champ *A et un seul champ *B peuvent être définis simultanément (cohérence des données faciles à assurer par une simple requête).
Ça te permet d'avoir une représentation non erronnée des relations (joueurA est une "vraie" clé étrangère, tout comme allianceA, joueurB, etc...), et d'avoir une clé primaire certes un peu grosses (tous les champs sauf "statut") mais qui a une signification immédiate (une clé primaire étant l'ensemble des clé étrangères signifie toujours une relation 0..1 avec les tables liées, ce qui est bien le cas).
Ça permettrait de normer un peu tout ça
Après à l'usage il faut voir. Tu as 3 solutions devant toi, celle que je viens de décrire est sans doute la plus adaptative car c'est celle du compromis entre le normage et la généricité.
RE: Besoin d'avis pour un problème de table - alfanor - 30-12-2007
Si je comprend bien donc, il me faudrait une table avec 6 clés étrangères, une clé primaire (donc id_relation c'est bien ça ?) et bien sûr l'id du statut de la relation ?
Mais c'est "légal" d'avoir 6 clés étrangères dont seulement deux seront exploitées ? Ou bien du moment que je ne met pas la table en InnoDB c'est bon ? (si j'ai bien compris les tables en MYISAM ne vérifie pas le fait que la clé est valide.)
RE: Besoin d'avis pour un problème de table - naholyr - 30-12-2007
alfanor a écrit :Si je comprend bien donc, il me faudrait une table avec 6 clés étrangères, une clé primaire (donc id_relation c'est bien ça ?) et bien sûr l'id du statut de la relation ?Il y aura 7 champs dans ta table (telle que conçue actuellement) : les 6 clés étrangères, et le statut. La clé primaire est composée des 6 premiers champs, donc pas de champ supplémentaire pour cette dernière.
Citation :Mais c'est "légal" d'avoir 6 clés étrangères dont seulement deux seront exploitées ?Aucun problème, une clé étrangère a le droit d'être NULL si on l'autorise, ça définit une relation "facultative", heureusement qu'on a le droit sinon comment exprimer le fait qu'un personnage peut avoir 0 ou 1 arme en main ?
La seule règle que ta table doit impérativement respecter pour la cohérence des données, et qui ne pourra être imposée par le schéma lui-même, c'est le fait qu'il doit y avoir 1 et 1 seul champ *A défini, et 1 et 1 seul champ *B défini.
Citation :Ou bien du moment que je ne met pas la table en InnoDB c'est bon ?Si si bien sûr, ta table a de *vraies* clés étrangères, c'est tout l'intérêt de cette version par rapport à la table "générique". Donc InnoDB est tout à fait adaptée.
La requête qui détecterait les incohérences pourrait ressembler à ça :
Code :
SELECT * FROM statut WHERE
-- pas de champ *A
(joueurA IS NULL AND territoireA IS NULL AND allianceA IS NULL)
-- pas de champ *B
OR (joueurB IS NULL AND territoireB IS NULL AND allianceB IS NULL)
-- deux champs *A ou plus
OR (joueurA IS NOT NULL AND territoireA IS NOT NULL)
OR (joueurA IS NOT NULL AND allianceA IS NOT NULL)
OR (territoireA IS NOT NULL AND allianceA IS NOT NULL)
-- deux champs *B ou plus
OR (joueurB IS NOT NULL AND territoireB IS NOT NULL)
OR (joueurB IS NOT NULL AND allianceB IS NOT NULL)
OR (territoireB IS NOT NULL AND allianceB IS NOT NULL)