Citation :À savoir que le champ 'type' dans les tables prérequis serait par exemple 'quete' ou 'batiment', c'est-à-dire ce sur quoi porte le prérequis. Ce qui me permet ensuite de comprendre le sens du #id du champ suivant
D'expérience, je peux te dire que ce genre d'approche, ça explose vite (= c'est la merde), car tu ne peux plus faire de jointure ni utiliser des clefs étrangères. Ca va te péter dans les doigts.
Mieux vaudrait, à ce compte-là, avec N colonnes dans la table de prérequis (une colonne par type) et mettre tout à NULL, sauf une. T'auras au moins les clefs étrangères et les jointures. Mais ce sera un peu la misère car tu vas avoir N colonnes (une par type, donc ici 4) dont une et une seule doit être non-NULL.
Pour ma part, je ferai plutôt cela {J'ai édité ce message pour ajouter la 2nde partie; j'aurai pu synthétiser, mais je préfère laisser le processus de pensée complet car je le trouve intéressant (et tant pis si ça sonne "je me jette des fleurs")}:
• 1 table pour chacun des domaines:
Batiment - Objets - Quetes - Technologies - Troupes
• 1 table pour chacun des types de prérequis:
PrerequisBatiment - PrerequisObjets - PrerequisQuetes - PrerequisTechnologies
• 1 table pour chacun des liens possibles:
Batiment _PrerequisBatiment - Batiment _PrerequisObjets - Batiment _PrerequisQuetes - Batiment _PrerequisTechnologies - Objets _PrerequisBatiment - Objets _PrerequisObjets - Objets _PrerequisQuetes - Objets _PrerequisTechnologies - Technologies_PrerequisBatiment - Technologies_PrerequisObjets - Technologies_PrerequisQuetes - Technologies_PrerequisTechnologies - Troupes_PrerequisBatiment - Troupes_PrerequisObjets - Troupes_PrerequisQuetes - Troupes_PrerequisTechnologies
C'est sûr, dit comme cela, ça fait un paquet de tables, mais mieux vaut beaucoup de tables élémentaires en charge d'une seule chose (d'une seule relation) que peu de tables qui font tout (et n'importe quoi). Ca répond à la problématique posée.
2e partie:
Maintenant, on lève une nouvelle problématique: ça fait plein de tables.
Donc, construisons un composant (une table) qui répond à cette problématique (qui n'a rien à voir avec la notion des prérequis/domaines). On a 4 types de prérequis et 5 domaines, soit 5x4=20 combinaisons. L'idée, c'est de faire un composant intermédiaire qui, à l'image d'une spec (genre HTML5) va faire passer de 5x4 combinaisons à 4+5 combinaisons. On va donc abstraire chaque moitié (domaine d'un coté, prérequis de l'autre) et on fera le lien entre ces abstractions:
• 1 table "abstraite" représentant un Domaine:
Domaine (id)
Ca fait pauvre en colonnes comme table, mais osef.
• 1 table pour chacun des domaines:
Batiment - Objets - Quetes - Technologies - Troupes
Avec une nouvelle colonne "idDomaine" qui fait référence à la table "Domaine::id"
• 1 table "abstraite" représentant un Prérequis:
Prerequis (id)
Ca fait là-encore pauvre en colonnes comme table, mais osef.
• 1 table pour chacun des types de prérequis:
PrerequisBatiment - PrerequisObjets - PrerequisQuetes - PrerequisTechnologies
Avec une nouvelle colonne "idPrerequis" qui fait référence à la table "Prerequis::id"
• 1 table unique liant le Domaine au Prérequis:
Domaine_Prerequis (id, idDomaine, idPrerequis)
La colonne "id" est facultative. Une clef unique (idDomaine, idPrerequis) sera utile.
Voilà
