Discussion :

[Kodut]

Bonjour tout le monde,
Je me suis lancé il y a quelques semaines dans la création d'une base de donnée en partant de 0 (aucune connaissance sql). J'utilise open office base.

Je bloque depuis plusieurs heures sur quelque chose. Voici grosso modo comment est faite ma base (et merci à ceux qui prendront le temps de lire et de m'aider)
J'ai une table client contenant des informations sur mes clients (nom, telephone) qui sont tous des gérants d'entreprise (une personne peut avoir plusieurs entreprises)
une table entreprise qui contient des information sur les entreprises de mes clients
une table facture contenant les informations des factures que j'adresse aux entreprises de mes clients.

Je souhaite sortir un rapport contenant les informations suivantes : les noms des entreprises qui n'ont pas encore payé leur facture, le montant de leur dette (somme des montants des factures impayées - somme des accomptes versés) ainsi que les noms des gérants et leur numéro de téléphone. J'ai donc besoin des informations provenant de 3 tables différentes.
J'arrive a faire toutes les opérations (sommes et différences) mettre des critères (réglement = 0) grouper le tout par nom d'entreprise, mais je n'arrive pas à joindre les 3 tables entre elles. Par exemple dans une requete j'arrive a afficher les noms des entreprises endettées, le nom et prénom du gérant et son numéro de téléphone mais pas les informations de la table facture comme le montant de la dette. Ou inversement j'arrive à afficher les noms des entreprises et le montant de leur dette mais pas les informations de la table client comme le nom du gérant et son numéro de téléphone.

Comment je peux faire ?

Merci par avance (en piece jointe un exemple de mon basard)

[punkoff]

bonjour,

indiquez la structure de vos tables, ainsi que les requêtes que vous avez déjà effectué

[Kodut]

T_client :
ID_client
nom_client
tel_client

T_entreprise :
ID_entreprise
ID_client
nom_entreprise

T_facture :
ID_facture
ID_entreprise
montant_facture
reglement_facture (oui/non)

La requete :

Code :

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

1
2
3
4
5
SELECT nom_entreprise, nom_client, tel_client, SUM( T_facture.montant_facture )
FROM T_entreprise, T_client, T_facture
WHERE T_entreprise.ID_client = T_client.ID_client 
AND T_facture.ID_entreprise = T_entreprise.ID_entreprise 
AND T_facture.reglement_facture = FALSE

le but est pour moi d'avoir les noms des entreprises n'ayant pas encore réglé leur facture, ainsi que le nom du client (qui est en fait le gérant de cette entreprise) et son numéro de téléphone, et la somme de tous les montants des factures impayées (d'ou le where reglement = false ou 0)

Ca ne fonctionne pas. Par contre si je n'utilise pas la fonction SUM ca marche mais le calcul n'est pas effectué et j'ai une ligne par facture non réglée, ce qui n'est pas ce que je souhaite (je veux vraiment afficher le total par entreprise). J'ai pensé à ajouter un GROUP BY sur ID_entreprise, mais sans succes.

[aieeeuuuuu]

Dans votre GROUP BY, mettez toutes les colonnes qui ne sont pas dans des fonctions d'agregat, en l'occurence :

Code :

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

1
2
 
GROUP BY nom_entreprise, nom_client, tel_client

[Kodut]

Bonjour et merci de votre réponse, c'est exactement ce qui m'a été conseillé sur un autre forum. Par contre je ne saisi pas la logique, pourquoi le GROUP BY nom_entreprise ne suffit pas ? en quoi est-ce que ca pose probleme?

Comprendre cela me permettrai de progresser dans le domaine, merci par avance !

[aieeeuuuuu]

vous regroupez par nom d'entreprise.

Pour chaque nom d'entreprise, vous avez donc potentiellement plusieurs "montant_facture" : vous spécifiez que vous voulez faire la somme des "montant_facture".

Par contre, si pour un nom d'entreprise donné, vous avez plusieurs nom_client ou plusieurs tel_client différents, quelle valeur mettre dans la colonne correspondante ?

donc soit vous groupez sur ces colonnes également (auquel cas, si pour un nom d'entreprise vous avez deux nom_client, vous aurez deux lignes distinctes dans le résultat), soit vous appliquez une fonction d’agrégat sur cette colonne pour indiquer quelle valeur mettre comme "nom_client"

[Kodut]

Ok, je comprend parfaitement, mais dans mon cas il ne peut pas y avoir plusieurs noms client et plusieurs numéros de téléphone par entreprise, c'est obligé qu'il n'y en ait qu'un seul. D'ou mon incompréhension sur la nécessité de grouper sur ces champs

[al1_24]

C'est une spécificité fonctionnelle que ne peut connaître le SGBD.

La règle est définie par la norme du langage SQL : toute colonne du SELECT qui ne fait pas l'objet d'une fonction de regroupement doit être reprise dans la clause GROUP BY.

Et les SGBD qui ne respectent pas cette règle retournent des informations potentiellement fausses.

[Kodut]

Ok merci. En fait je pensais que si la structure de la base ne permettait pas , dans mon cas, d'avoir plusieurs client par entreprise, alors il n'était pas necessaire de faire ce group by

Merci pour vos réponses

[aieeeuuuuu]

En fait je pensais que si la structure de la base ne permettait pas , dans mon cas, d'avoir plusieurs client par entreprise, alors il n'était pas necessaire de faire ce group by

Pour compléter ce qu'a dit al1_24, c'est plus ou moins ce qu'autorise la norme SQL, les colonnes n'étant pas dans des fonctions d'agrégat ne sont pas réquises dans le group by à la condition qu'elles dépendent fonctionnellement de l'une des colonnes du GROUP BY.

Mais à ma connaissance, aucun SGBDR n'implémente cette subtilité.

[CinePhil]

Pour compléter ce qu'a dit al1_24, c'est plus ou moins ce qu'autorise la norme SQL, les colonnes n'étant pas dans des fonctions d'agrégat ne sont pas réquises dans le group by à la condition qu'elles dépendent fonctionnellement de l'une des colonnes du GROUP BY.

Mais à ma connaissance, aucun SGBDR n'implémente cette subtilité.

Ben si, MySQL mais en autorisant aussi la chose lorsque les colonnes absentes du GROUP BY ne sont pas directement dépendantes de celles qui s'y trouvent, ce qui peut effectivement donner des résultats faux. C'est pour ça qu'il vaut mieux s'habituer, même avec MySQL, de faire les choses bien !

[aieeeuuuuu]

Ben si, MySQL mais en autorisant aussi la chose lorsque les colonnes absentes du GROUP BY ne sont pas directement dépendantes de celles qui s'y trouvent

Justement, je n'appelle pas ça implémenter la subtilité...
à la rigueur, "manquer de subtilité dans l'implémentation", mais c'est vraiment pour rester poli