Re: aide sur requete avec jointures
seb seb Wrote:
-------------------------------------------------------
> Je suis tout à fait d'accord avec toi au sujet de
> l'importance de la conception du model. Et je suis
> prêt à en changer si on me démontre qu'il ne
> convient pas.
Il est vrai que j'ai tendance à insister lourdement sur ce point, je regrette d'être quasiment le seul à faire du soutien sur le forum « french » de MySQL, d'autres avis seraient sûrement bienvenus.
Ceci étant comme je l'ai mentionné, je parle par expérience. Aujourd'hui, on ne développe quasiment plus rien sans une base de données derrière. La base de donnée est devenu un cœur assez crucial pour toute application un tant soit peu dynamique. J'ai aussi pu constater avec les années qu'une très faible proportion de développeurs professionnels (ou prétendus tels ;-) ) sait réellement modéliser une base de données. La méthode MERISE en la matière n'est connue que de peu de gens et c'est tout à fait regrettable parce que ce sont des fondamentaux en développement. Des données doivent être convenablement structurées, on doit éviter comme la peste les redondances inutiles qui rendent les mises à jours des données pénibles ou simplement lourdes parce qu'on doit faire davantage de requêtes là où une seule aurait suffi dans un modèle bien conçu.
Je ne le dirai jamais assez : le développement, c'est plus de la moitié du temps en analyse, on écrit pas de code, on fait des croquis, on identifie des données, on isole des groupes de données cohérents, on relie les éléments les uns aux autres en fonction des règles de gestion définies par l'utilisateur qui attend une application.
J'ai effectué il y a maintenant environ trois ans une maintenance sur une application qui avait été créée un an auparavant par un collègue. Dans les fonctionnalités attendue, il y en avait une que le client attendait toujours... et pour cause : dans l'état du moment de la base, c'était mission impossible de réaliser ça parce qu'il y avait un vice de conception dans la structure des données. La seule solution restant était de refaire cette partie de la base. Malheureusement, cette partie était le cœur même de ladite base et 80% du requêtage passait par là. Je pensais avoir trouvé une astuce avec une requête à coucher dehors : j'ai livré au client en le mettant en garde : livraison sans garantie, je n'ai pas vu de soucis, mais il y aura peut-être des effets de bord imprévus, gardez l'ancienne version sous le coude. Ça n'a pas loupé, trois mois plus tard au retour d'une autre mission, il a fallu casser le modèle, le reconstruire proprement et refaire toutes les requêtes SQL qui passaient par là. Résultat, si on compte bien, si mon prédécesseur avait passé quatre ou cinq jours de plus à analyser son modèle de données, je n'aurais pas passé`(de mémoire) une trentaine de jour à réparer sa boulette.
Non, ce n'est vraiment pas une perte de temps de recommencer surtout quand on en est encore au début du développement. ;)
Dans le modèle que je te suggère, tu peux en fin de compte justement avoir plusieurs référence à une même ligne d'une table fille pour une ligne d'une table parente, mais pose-toi la question des relations entre les données : le classement concerne la ligne de la table fille, et non la ligne de la table parente, il n'y a donc aucune raison technique validant le besoin de lier le classement à la table parente en même temps qu'à la table fille, seule concernée. Tu retrouveras toutes tes correspondances pour un module donné par transitivité, tu n'auras quasiment aucune valeur NULL, ça c'est quand même préférable, et tu n'auras aucune redondance de données nulle part.
Tu peux préférer ton modèle d'origine, mais crois moi, dans six mois, tu vas pleurer ta mère et tu te taperas la tête sur les murs en disant « Mais pourquoi je l'ai pas écouté » ;-)
______________________________________________________________
Une question bien formulée, c'est un problème bien compris : ça représente déjà les 3/4 de la réponse ;)