Question

J'ai une requête qui comporte 7 jointures internes (car une grande partie des informations est distribuée dans d'autres tables), quelques collègues ont été surpris. Je me demandais s’ils devraient être surpris ou s’ils avaient 7 jointures intérieures normales?

Était-ce utile?

La solution

ce n'est pas du jamais vu, mais je le placerais dans une vue pour en faciliter l'utilisation et la maintenance

Autres conseils

Deux questions:

  1. Est-ce que ça marche?
  2. Pouvez-vous l'expliquer?

Si oui, alors sept c'est bien. Si vous ne pouvez pas expliquer la requête, alors sept c'est trop.

Il est normal que votre schéma se trouve dans la cinquième forme normale :)

En fonction de ce que vous essayez d'accomplir, un grand nombre de jointures dans une requête n'est pas remarquable.

Personnellement, je serais moins préoccupé par le nombre de jointures utilisées pour renvoyer un ensemble de résultats souhaité, mais plutôt par le fait que la requête soit optimisée et qu'elle respecte les paramètres acceptables.

Si la requête est entièrement optimisée et ne peut pas être réduite, mais que la requête elle-même ne s'exécute pas assez rapidement, il est possible que la conception de la structure de données ne corresponde pas parfaitement à ce que vous essayez de faire. Vous pouvez alors réévaluer ce que vous essayez d'accomplir ou la structure des données qui alimentent votre modèle économique.

Ce n'est pas du tout inhabituel. Avec un système comme Siebel, il est courant de voir les comptages de jointures à deux chiffres.

Sept jointures compliquent la lisibilité, mais les performances et l'évolutivité sont plus importantes. Si cela vous convient, allez-y.

Ce n'est probablement pas normal mais ce n'est certainement pas excessif. Si vous vous retrouvez encore et encore dans les mêmes tables, créez des vues.

Le nombre de jointures dépend de votre modèle de données, 7 jointes peuvent être dans votre requête si c'est ce que vous demandez - je me souviens d'avoir des requêtes similaires dans une application sur laquelle j'ai travaillé il y a longtemps, les performances dépendent de nombreux facteurs (tableau taille, index, charge du serveur, configuration du serveur pour nommer quelques-uns) et je ne pense pas que l'on puisse généraliser que 7 jointures sont mauvaises.

si cela fonctionne pour vous alors je suppose que c'est bien: D

Oui, c'est normal - mais, en réalité, ce n'est pas une si bonne idée du point de vue des performances. Les plans de requête reposant sur des coûts estimés , il existe un augmentation du nombre d'erreurs à mesure que vous augmentez les jointures (ou tout autre opérateur, d'ailleurs):

  

L'optimiseur de requêtes SQL Server estimera au moins une ligne sortant d'un opérateur de recherche. Ceci est fait pour éviter le cas où un sous-arbre très coûteux est sélectionné en raison d'une sous-estimation de la cardinalité. Si on estime que la sous-arborescence ne renvoie aucune ligne, de nombreux plans coûtent à peu près le même prix, ce qui peut entraîner des erreurs de sélection de plan. Ainsi, vous remarquerez que l’estimation est «élevée» pour ce cas, et que des erreurs pourraient en résulter. Vous remarquerez peut-être également que nous estimons 20 exécutions de cette branche au lieu de la réelle 10. Cependant, étant donné le nombre de jointures évaluées avant cet opérateur, un facteur 2 (10 lignes) n'est pas considéré comme étant dommage. ( Les erreurs peuvent augmenter de manière exponentielle avec le nombre de jointures ).

En outre, l’optimiseur tente d’équilibrer le temps requis pour élaborer un plan par rapport aux économies potentielles. Il ne passe pas toute la journée à essayer de trouver le plan le plus optimal. Plus le nombre de jointures est élevé, plus il existe de plans alternatifs, dont certains sont peut-être plus optimaux que l'optimiseur n'a le temps de trouver.

7 ou même plus n’est pas inhabituel dans les entrepôts de données où une table de faits pourrait facilement avoir des clés étrangères d’une douzaine de dimensions. Dans le scénario de l'entrepôt de données, la cardinalité des dimensions est généralement faible comparée à la table de faits. Par conséquent, les filtres sur les dimensions permettent d'utiliser la table de faits par le biais d'une recherche d'index ou d'une analyse.

Pour un schéma transactionnel normalisé, le fait que la cardinalité de l'ensemble de résultats soit faible dans la table de base principale (c'est-à-dire tout sélectionner pour un client) ne pose généralement pas de problème, car les clés étrangères peuvent normalement simplement entraîner des recherches d'index ou analyses d'index.

7 est acceptable si la conception de votre base de données l’exige. Cependant, si 7 est nécessaire pour atteindre votre objectif, je réexaminerai la conception de la base de données pour m'assurer que ce niveau d'obscurité est vraiment nécessaire.

Par curiosité, s'agit-il de DB2? Juste un motif que j'ai remarqué:)

S'agit-il de 7 jointures internes sur la même table, 7 jointures internes sur des tables différentes ou 7 jointures internes imbriquées ?

... question piège! Peu importe vraiment, si telle est la structure de votre base de données, alors elle est correcte

mise en garde: s'il y a 7 jointures internes imbriquées sur la même table, vous avez probablement une table mal structurée; -)

Ce n'est certainement pas inhabituel. Cependant, au moins dans Oracle, 7 est un nombre spécial, car il n’est pas plus que cela et que l’optimiseur ne peut plus tester chaque ordre de jointure (en raison de la croissance factorielle du nombre de possibilités). Il serait donc sage d'éviter de dépasser 7 si vous n'êtes pas disposé à garder votre plan d'exécution.

Je pense que ce que vous voulez éviter, c'est une profondeur de jointure supérieure à 7. 7 jointes intérieures de moins de 7 jointures en profondeur ne sont certainement pas inouïes, mais il arrive que des gens entendent "7 jointures". et pensez que le non-non est de 7 jointures, pas de profondeur.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top