Discussion :

[zarbouine]

Bonjour,

j'ai trois tables : clients, commandes, détails
- détails est lié à commandes par le n° de commande NUMCOM
- commandes est lié aux clients par le n° de client NOCLI

Je veux la liste des clients qui ont commandé un article donné 'xxxxxx', avec le prix payé et la date de la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT clients.nom, commandes.datecom, details.pu, details.code_article FROM clients, commandes, details
WHERE  details.code_article='xxxxxx'
AND commandes.numcom=details.numcom AND clients.NOCLI=commandes.NOCLI

Je récupère bien les colonnes nom du client, date de la commande, mais pas le pu...
J'ai beau chercher, je ne vois pas

[SergioMaster]

Bonjour,

Si vous aviez fait une requête "normalisée" en spécifiant correctement les jointures peut-être aurait-ce été plus flagrant.

Je veux la liste des clients qui ont commandé un article donné 'xxxxxx', avec le prix payé et la date de la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT clients.nom, c.datecom, d.pu, d.code_article 
  FROM Details D JOIN COMMANDES C ON c.numcom=d.numcom
                         JOIN CLIENTS on clients.NOCLI=c.NOCLI
WHERE d.code_article='xxxxxx'

[zarbouine]

oui, je suis d'accord c'est plus lisible ! Merci !
En fait, ça marchait, la colonne pu était vide dans la table pour les trois codes articles que je testais ! Quelle andouille je fais....

[escartefigue]

Bonjour,

Le fait que PU soit vide ne change rien à l'affaire puisque la colonne PU n'est ni un critère de jointure, ni un critère de restriction...

Pour plus de lisibilité, il faut non seulement coder les jointures avec l'opérateur JOIN pour distinguer ce qui concerne la jointure de ce qui concerne la restriction, mais aussi affecter un alias à chaque table, pour identifier facilement quelle colonne provient de chaque table.

Le tout avec une présentation soignée qui permet de maintenir plus facilement les requêtes.

Exemple :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
SELECT CL.nom
     , CO.datecom
     , DT.pu
     , DT.code_article 
FROM       clients   as CL
inner join commandes as CO
   on CO.NOCLI=CL.NOCLI
inner join details   as DT
   on DT.numcom=CO.numcom 
WHERE  DT.code_article='xxxxxx'

[SergioMaster]

Bonjour,

c'est vrai que, par flemme, je n'ai pas mis d'alias à la table CLIENTS, ni le INNER du JOIN (INNER étant par défaut, du moins est-ce ce que je compris, pour Firebird

JOIN is same as INNER JOIN

).

Autre point j'aime mettre les tables en ordre "décroissant" donc détails,commandes,clients est-ce une bonne chose @escartefigue en tant que bourreau si tu repasses ici j'aimerai bien avoir ton avis

[escartefigue]

Bonjour Sergio,

Ma remarque s'adressait surtout à zarbouine qui n'avait pas utilisé d'alias du tout.

L'ordre des tables n'a aucune importance, l'optimiseur n'en tient pas compte pour construire sa stratégie, si c'est plus confortable à la lecture, je n'y vois aucun inconvénient, mais bizarrement, j'aurais plutôt choisi la logique inverse en allant de la table dont la population est la plus réduite vers celle dont la population est la plus importante, soit

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
FROM CLIENT CL
INNER JOIN COMMANDE CO
   ON...
INNER JOIN DETAIL DT
   ON...

[SergioMaster]

L'ordre des tables n'a aucune importance, mais bizarrement, j'aurais plutôt choisi la logique inverse

Comme quoi tous les goûts sont dans la nature il serait interssant de voir comment l'optimiseur arrange ça (histoire de lui mâcher le travail) si j'ai du temps à perdre ...

[zarbouine]

Bonsoir à tous les deux,

discussion intéressante, j'en prends de la graine...
étonnant la souplesse de SQL, il accepte des syntaxes variées et est bluffant de rapidité pour moi qui vient du BDE !

Il n'y a qu'une chose regrettable c'est la lenteur de la contruction des index par FBQuery à l'ouverture du query. Par exemple sur une table de quelques dizaines de milliers d'enregistrements, on pouvait utiliser instantanément les index existants sur les tables (dBase et Paradox), sans qu'il ne soit besoin de construire à chaque ouverture, alors qu'avec Firedac, il prend quelques secondes pour construire son index quand on l'ouvre....ce qui encourage à refaire une requête (très rapide si l'index existe dans la base) plutôt qu'utiliser les index.... ou bien je m'y prends comme un un manche ?

[SergioMaster]

Bonjour

Il n'y a qu'une chose regrettable c'est la lenteur de la contruction des index par FDQuery à l'ouverture du query.

ce qui déborde de ce forum puisque là on est plus sur Delphi et un type particulier de composant d'accès aux données

Par exemple sur une table de quelques dizaines de milliers d'enregistrements, on pouvait utiliser instantanément les index existants sur les tables (dBase et Paradox), sans qu'il ne soit besoin de construire à chaque ouverture

Parce qu'ils étaient construits, les extensions DBX etc...

Alors qu'avec Firedac, il prend quelques secondes pour construire son index quand on l'ouvre....

Les Threads ça existe

ce qui encourage à refaire une requête (très rapide si l'index existe dans la base) plutôt qu'utiliser les index...

.
Moi je trouve que récupérer "des dizaines de milliers d'enregistrements" c'est largement trop aucun utilisteur ne lira le tout , donc faire une requête restrictive (where, rows, order) est largement mieux

ou bien je m'y prends comme un un manche ?

peut-être un peu il faut se débarasser en premier lieu des réflexe paradox

Mais, ce débat, n'a rien à faire dans ce forum, tout à voir dans le forum Delphi/Base de données

[zarbouine]

Exact, je me suis laissé aller...