[réglé] Un peu d'organisation... pour les performances

[uriak]

Aller je relance un peu Je ne cherche pas LA solution à tel ou tel problème, mais suis à la recherche de "bonnes pratiques"

Donc sujet de débat : je cherche à gérer des arbres de compétences ("graphe" étant plus exact")
On me propose la table suivante :
Relations (id_comp, id_subcomp, dep_value) (identifiant compétence, compétance requise, level de requis)
{
3,0,1
4,1,2
4,0,1
}

couplée avec une table de compétence possedant la cled servant aux id
Mais si maintenant j'introduit un arbre de technologies, qui entraînent d'autres dépendances :
exemple : "forge : acier sanglant" nécessite "forge" et "technologie : alliages supérieurs"

devrais-je m'orienter vers deux tables : dépendances comp, dépendances tech ?
ou une table unique de la forme ?
Relations (id_comp, id_dep, type_dep, level_dep)
avec un short/char/petit entier type_dep qui me donne le type de dépendance et donc le type d'identificateur contenu dans id_dep (qui peut donc être une compétence ou une techno).

Pire si je veux que les techno dépendent de techno ET de compétences (ha que je veux faire un jeu subtil, moi ^^ ) Si je choisis une table unique cela donnera :
Relations (id_rel, id_dep, type_dep, level_dep) avec cette fois id_rel ET id_dep pouvant se référer à une compétence OU une techno et type_dep donnant toujours le type de relation et donc la nature de id_dep et id_rel. par ex :
0 : comp -> comp
1 : comp -> tech
2 : tech -> comp
3 : tech -> tech

donc à votre avis une telle implémentation est-elle à privilégier plutôt que celle de 4 tables de relations ?

Et une dernière chose : dans le cas de joueur avec un inventaire, une liste d'amis, de comp, etc... vous auriez tendance à faire une table par joueur, ou faire des tables de relations semblables à celles dont j'ai parlé ? Dans le cas des tech/comp, ce sont des données sous contrôle des admins, alors que les joueurs s'inscrivent et évoluent à leur gré, donc les chiffres sont incontrôllables...