30-12-2007, 01:08 PM
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é.
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é.
Ressources [PHP][MySQL][![[Image: fav.png]](http://prototypejs.org/images/fav.png)
prototype.js]
prototype.js]