IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage SQL Discussion :

Limitation du nombre de jointures / problème de conception / MySQL


Sujet :

Langage SQL

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 12
    Points : 16
    Points
    16
    Par défaut Limitation du nombre de jointures / problème de conception / MySQL
    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.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 902
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 902
    Points : 53 143
    Points
    53 143
    Billets dans le blog
    6
    Par défaut
    Pour votre exemple d'imbrication géographique qui à mon sens est idiot, il suffisait de ne faire qu'une seule table avec une imbrication arborescente, le niveau d'imbrication donnant le type de zone géo;
    Exemple :
    niveau 0 = univers
    niveau 1 = galaxie
    niveau 2 = système solaire
    niveau 4 = planète
    niveau 5 = continent
    niveau 6 = pays
    niveau 7 = région (F), lander (D)
    niveau 8 = département
    niveau 9 = ville
    ...
    Et comme MySQL ne gère pas les requêtes récursives, vous devez utiliser la représentation intervallaire pour ce faire.
    Lisez l'article que j'ai écrit à ce sujet :
    http://sqlpro.developpez.com/cours/s...te-recursives/
    http://sqlpro.developpez.com/cours/arborescence/

    Entre nous, vous n'avez pas autre chose à faire que de réinventer une roue carré et constater que ça marche pas ou bien êtes vous masochiste ?

    A +

Discussions similaires

  1. limiter le nombre des lignes d'une table MYsql
    Par ikrambh dans le forum Requêtes
    Réponses: 2
    Dernier message: 31/08/2013, 15h09
  2. Réponses: 5
    Dernier message: 11/12/2007, 14h44
  3. Réponses: 29
    Dernier message: 26/06/2006, 12h17
  4. limiter le nombre d'enregistrements d'une jointure
    Par dubem1 dans le forum Langage SQL
    Réponses: 1
    Dernier message: 19/12/2005, 08h29
  5. limitation du nombre d'enregistrement sur une jointure
    Par coredump dans le forum Langage SQL
    Réponses: 2
    Dernier message: 18/06/2005, 16h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo