Devoir refaire un modèle et reprogrammer ce qui est fait n'est pas une perte de temps. Si un modèle est bancal au départ, l'application la mieux codée restera bancale.
Il semble qu'un élément manquait dans les règles de gestion de début, du coup je suis parti sur une idée incomplète. Je ne saisis pas bien la raison de ce besoin spécifique de pouvoir associer plusieurs fois la même ligne d'une table à la ligne d'une autre table avec des classements différents. Mais à la limite peu importe.
Ce qu'il faut comprendre lorsqu'on modélise une base, ce sont les relations entre les données et les cardinalités, c'Est à dire, le nombre de fois où une donnée sera reliée à une autre et selon quel(s) critère(s).
Si je me base sur tes dernières observations, je modifie alors le modèle comme suit :
+----------------+ +-------------------+ +------------------+ +-------------------+
| modules | | chapitres | | briques | | sequences |
+-----------+----+ 0/n 1/1 +--------------+----+ 0/n 1/1 +-------------+----+ 0/n 1/1 +--------------+----+
| idmodule | PK |-----------| idchapitre | PK |-----------| idbrique | PK |-----------| idsequence | PK |
| nommodule | | | idmodule | FK | | idchapitre | FK | | idbrique | FK |
+-----------+----+ | nomchapitre | | | nombrique | | | nomsequence | |
+--------------+----+ +-------------+----+ +--------------+----+
| 0/n | 0/n | 0/n
| | |
| | |
| 1/1 | 1/1 | 1/1
+------------------+ +----------------+ +-----------------+
| classmtchapiptre | | classemtbrique | | classmtsequence |
+-------------+----+ +-----------+----+ +------------+----+
| idcch | PK | | idcbr | PK | | idcs | PK |
| idmodule | FK | | idbrique | FK | | idsequence | FK |
| ccrank | | | cbrank | | | csrank | |
+-------------+----+ +-----------+----+ +------------+----+
Là, je vire le classement des tables chapitres, briques et séquences parce qu'une même ligne d'une de ces entités peut avoir plusieurs classements. Or on sait déjà qu'un élément d'une entité fille ne peut être reliée qu'à 0 ou 1 ligne de l'entité parente. Attention à ce point, réfléchis soigneusement, si cette affirmation est fausse, alors le modèle corrigé ci-dessus ne sera pas bon.
Du coup, en partant sur cette nouvelle base, ma requête devient alors :
SELECT
mo.nommodule,
ch.nomchapitre,
br.nombrique,
se.nomsequence
FROM modules mo
INNER JOIN chapitres ch ON mo.idmodule = ch.idmodule
INNER JOIN classmtchapitre cc ON ch.idchapitre = cc.idchapitre
INNER JOIN briques br ON ch.idchapitre = br.idchapitre
INNER JOIN classmtbrique cb ON br.idbrique = cb.idbrique
INNER JOIN sequences se ON br.idbrique = se.idbrique
INNER JOIN classmtsequence cs ON se.idsequence = cs.idsequence
WHERE mo.idmodule = 1
ORDER BY
mo.idmodule,
cc.rankchapitre,
cb.rankbrique,
cs.ranksequence;
Je te suggère vivement de soigneusement analyser ça : tu perdras moins de temps à refaire l'actuel qu'à tenter ultérieurement de trouver comment contourner un vice de conceptions plus tard sur une application en production, et crois-moi, je te parle par expérience professionnelle. Tu auras peut-être l'impression de perdre deux jours en refaisant un boulot, mais c'est nettement moins grave que de repasser plus tard 12 jours sur des corrections et tentatives de rattrappage plus ou moins possibles.
______________________________________________________________
Une question bien formulée, c'est un problème bien compris : ça représente déjà les 3/4 de la réponse ;)
Edited 1 time(s). Last edit at 08/18/2010 07:01AM by Jean Molliné.