Discussion :

[Pach30]

Bonjour

Je développe le titre . J'avais "pondu" une requête" qui me donnait satisfaction avec le jeu de données que j'utilisais . hélas , patatras , avec un nouveau jeu fourni par mon client , ce ne réponds plus (pas) comme je l'espère . J'ai parcouru le site , feuilleté un certain nombre de bouquin sur SQL mais je n'ai pas trouvé de méthode pour concevoir une requête parfaite à la premiere écriture . Auriez vous des documents /liens qui pourraient me guider ?

Merci d'avance

[tatayo]

Bonjour,
Tu ne précises pas ici quel a été le problème rencontré, mais quoi qu'il en soit je ne pense pas qu'il existe de méthode "universelle" pour avoir la bonne requête du premier coup, surtout si celle-ci est un tant soit peu complexe.

Il y a tout de même des erreurs classiques, par exemple l'hypothèse du monde clos, qui fait qu'on ne choisit pas toujours la bonne jointure.
la propagation des nuls dans des calculs, une jointure qui ramène plus de ligne que prévu et qui "fausse" les agrégats…

Bref dès qu'un formule une hypothèse, par exemple un article a toujours une marque, un ticket de vente est toujours lié à un client, il convient de la vérifier (ici en vérifiant les cardinalités).

Tatayo.

[Pach30]

Effectivement , c'est sans aucun doute sur les choix de jointure que je pêche . Je sais quelles données je veux récuperer et que celles-ci sont réparties sur plusieurs tables et qu'il faut que je passe par des tables auxiliaires (lé schéma a été généré à partir de Django ). J'imagine que l'ordre dans lequel on enchaine les jointures à un impact . Pour parler concrétement , dans mon cas , les données que je veux sont dans 2 tables différentes mais ii faut que je passe par 4 tables supplémentaires pour avoir le résultat final.
Je ne quand même assez surpris qu'il n'y ait pas une méthodologie pour la construction d'une requête .

[Pach30]

un début de réponse ici ?

https://sqlpro.developpez.com/cours/sqlaz/jointures/

La jointure de multiples tables peut se représenter sous la forme d'un arbre. Cet arbre possède donc une racine, c'est la table principale, celle d'où l'on veut que l'information parte. Elle possède aussi des feuilles, c'est-à-dire des tables d'entités. Les tables situées entre la racine et les feuilles sont souvent des tables de jointure, possédant en principe deux clefs étrangères. Dans le principe toute table de jointure devrait être un nœud de l'arbre.
La représentation arborescente d'une jointure est un excellent moyen pour visualiser si la clause de jointure de votre requête est à priori correcte. En effet, une référence circulaire dans la clause de jointure ne peut pas être représentée sous la forme d'un arbre et il y a fort à parier que la requête soit incorrecte.

[Waldar]

Je ne quand même assez surpris qu'il n'y ait pas une méthodologie pour la construction d'une requête .

Ca dépend ce que vous entendez par méthodologie.
En tout cas il y a plusieurs méthodologie de modélisation de base de données, et c'est là le nerf de la guerre.

La méthodologie de construction de requête c'est de commencer par le début de votre besoin (une table client avec un client par exemple), et d'étendre au fur et à mesure en vérifiant à chaque nouvelle étape (que ce soit une jointure, un filtre, une expression) que le résultat est conforme à vos attentes.
Comme vous l'avez compris, les données que vous regardez ne reflètent pas l'intégralité des règles de gestion à implémenter, c'est pour ça qu'une bonne modélisation avec contraintes est importante. Si en plus vous pouvez discuter avec des chefs de projets fonctionnel (ou PO/PM si vous êtes agile) qui vous donneront des règles plus exhaustives, ça vous permet d'être plus fin dans votre code.

[vanagreg]

Bonjour,

Déjà il faut que le modèle de données soit bien fait, ce qui est rarement le cas.
La première chose à faire est de bien mettre au clair le besoin. Donc identifier les tables dans lesquelles se trouvent les informations dont on a besoin (et c'est souvent ça la grande difficulté quand on ne connait pas bien le modèle!).
Une fois les tables identifiées, il faut savoir comment les joindre.
Normalement quand je n'ai pas besoin des colonnes d'une table impliquée, je la place dans un semi-join (condition EXISTS). Si le besoin est un peu compliqué, alors il y a de très fortes chances que je fasse intervenir des fonctions analytiques. Ensuite ça peut-être parfois de la subtilité, par exemple transformer des conditions OR en UNION ALL, ou encore transposer des lignes en colonnes pour réduire la cardinalité. Ecrire des requêtes SQL c'est un peu comme de l'art. La quasi totalité des problèmes de performance viennent d'un modèle mal conçu et/ou de requêtes mal écrites.

[Pach30]

Bonjour,

Déjà il faut que le modèle de données soit bien fait, ce qui est rarement le cas.

Bon , la , je commence mal déja puisque le modèle de donnée a été generé par "Django " ( quoique Reinhardt , c'était un artiste , non ? )

La première chose à faire est de bien mettre au clair le besoin. Donc identifier les tables dans lesquelles se trouvent les informations dont on a besoin (et c'est souvent ça la grande difficulté quand on ne connait pas bien le modèle!).

ici , je sais

Une fois les tables identifiées, il faut savoir comment les joindre.

ah , j'ai bien identifié la ou je coince

Normalement quand je n'ai pas besoin des colonnes d'une table impliquée, je la place dans un semi-join (condition EXISTS). Si le besoin est un peu compliqué, alors il y a de très fortes chances que je fasse intervenir des fonctions analytiques. Ensuite ça peut-être parfois de la subtilité, par exemple transformer des conditions OR en UNION ALL, ou encore transposer des lignes en colonnes pour réduire la cardinalité. Ecrire des requêtes SQL c'est un peu comme de l'art. La quasi totalité des problèmes de performance viennent d'un modèle mal conçu et/ou de requêtes mal écrites.

Pour l'instant , j'essaye le technique de l'arbre et ca m'a permis de progresser (par ex j'avais construit ma requête à l'inverse en partant des résultats que je voulais donc en descendant dans les tables plutôt que des données présentes à remonter dans le résultat )

[vanagreg]

Bon , la , je commence mal déja puisque le modèle de donnée a été generé par "Django " ( quoique Reinhardt , c'était un artiste , non ? )

On serait plutôt Jango Edwards ici

[SQLpro]

... J'imagine que l'ordre dans lequel on enchaine les jointures à un impact ....

Dans un bon SGBDR non (Microsoft SQL Server, Oracle, IBM DB2) dans un mauvais oui (PostGreSQL, MySQL...) L'optimiseur est là pour choisir l'ordre de jointure le plus judicieux pour économiser les ressources...

Pour parler concrétement , dans mon cas , les données que je veux sont dans 2 tables différentes mais ii faut que je passe par 4 tables supplémentaires pour avoir le résultat final.
Je ne quand même assez surpris qu'il n'y ait pas une méthodologie pour la construction d'une requête .

Cela fait 5 jointures ce qui n'est pas le bout du monde. Cela ne devrait pas être lent si :
1) la base est bien modélisée (respect des formes normales)
2) la base est bien indexée
3) l'optimiseur est de qualité

Dans le pire des cas il existe des moyens d'optimiser encore plus comme les vues indexées par exemple.
À lire : https://www.developpez.net/forums/d6...t/vue-indexee/

A +