Bonjour,
Je me heurte à une limitation de MySQL au niveau du nombre limité de jointure qui remet en cause ma façon, je pense, de concevoir.
J'ai développé un outil assez complexe qui, pour faire simple, génère à partir d'un modèle de données un ensemble de classe permettant de manipuler les tables de ce modèle, en particulier de d'affranchir des soucis de cascades/dépendances lors de suppressions d'enregistrements sur des tables en relation.
Le but avoué de cet outils est de permettre de manipuler de manière transparente des tables au format MyISAM, sans avoir recours à des triggers ou procédures stockées. Mon parti prit derrière cela est de m'affranchir de toute spécificité du SGBD et ainsi d'avoir tout le code métier au meme endroit (j'insiste que c'est mon choix aussi je ne voudrais pas relancer de polémiques à ce sujet).
Alors voilà, les nuits blanches se sont empilées, l'outil fonctionne à merveille, de belles requêtes s'affichent à l'écran tout va bien, ou plutôt « allait » bien.
J'ai en effet décidé d'utiliser ce générateur pour un projet « réel », une sorte de gestionnaire au modèle assez touffu.
Et là, patatra, MySQL m'annonce que sa limitation en nombre de jointure est de 61. J'ai trainé mes godillots sur pas mal de forums, il en ressort qu'il y a bien une manière d'overrider cette limite mais globalement le retour des utilisateurs préconise de revoir le modèle.
Chose que j'ai faite. Et, je n'ai rien changé car je ne vois pas quoi changer. Prenons un exemple, un modèle « Univers » simple :
Dans cet exemple, on exprime ici la représentation d'un univers. Dans la version simple, un quartier contient des habitations. Des utilisateurs peuvent intervenir sur cet univers et créer un quartier et/ou des habitations. Pour chacune de ces entité, on souhaite conserver la trace du créateur. Qui a créé tel quartier ? Qui a créé tel habitation ? D'où une relation de chacune de ces entité vers une table utilisateur.
Jusque là rien de bien compliqué.
Si je veux supprimer un utilisateur, il faudra :
1 – supprimer les habitations qu'il aura créé
2 – supprimer les quartiers qu'il aura créé et, par répercussion, les habitations qui font parties de ce quartier.
Ceci nous donne 3 jointures à mettre en place dans notre requête DELETE que j'exprime par la formule suivante :
Soit J, le nombre de jointure
et T, le nombre de tables :
J = T + (T - 1) * ( T / 2)
Dans notre exemple : J = 2 + (2 - 1) * (2 / 2) = 3.
Tout va bien. Maintenant, si je prends mon modèle « Univers » au complet, il comporte bien plus d'entités, toutes reliées les unes aux autres :
Si je veux appliquer une requête DELETE pour supprimer un utilisateur, je vais avoir un nombre important de jointures.
En reprenant ma formule :
J = T + (T - 1) * ( T / 2)
Avec 11 Tables, le nombre de jointures se monte à... 66, et là MySQL renvoie sa politesse d'usage :
« Too many tables; MySQL can only use 61 tables in a join ».
Ci-dessous un tableau qui illustre le nombre de jointure par entité ajoutée pour une requête DELETE :
A ce stade, je remets pas mal de choses en causes et suis à deux doigts de mettre mon applis à la benne non recyclabe.
Comme je l'ai exprimé plus haut, je ne veux pas utiliser de mécanismes interne au SGBD pour gérer les dépendances et je veux utiliser le type MyISAM pour mes tables.
Je pourrais toujours repasser après mon outil et m'amuser à découper mes requêtes DELETE en plusieurs pour diminuer mon nombre de jointures mais ça ne me plait évidemment pas, l'intérêt de l'outil dans ces conditions est à remettre complètement en cause.
J'en reviens plus au modèle « Univers » lui-même à concevoir. Ce fameux univers, même si l'exemple est un peu tiré par les cheveux, on peut j'imagine retrouver ce genre d'organisation dans d'autre exemples. Une chaine d'entités reliées les unes aux autres où l'on conserve la trace d'un créateur, je ne dois pas être le seul à imaginer ce genre de choses.
La requête DELETE pour être cohérente s'effectue en une fois et utilise toutes ces jointures alors j'en suis à remettre complètement en cause ma façon de concevoir ce modèle « Univers ». Je ne vois pas ce qui cloche, je ne vois pas comment le représenter autrement, j'ai peut-être tout faux.
Dans ce contexte, et je fais appels à vos retours d'expériences :
Peut-on représenter le modèle « univers » de façon différente ?
Suis-je fatalement obligé d'avoir recours à des mécanismes internes du SGDB ?
Suis-je fatalement obligé d'abandonner le type de table MyISAM pour InnoDb ?
Je suis dans le flou complet... Merci pour vos lumières.
Partager