et j'effectue la requête suivante afin de récupérer les montants des
commandes par mois :
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
facture_echeance_mois FROM facture, commande WHERE commande.facture = '1'
AND YEAR(facture.echeance)='2007' AND facture.commande_id = commande.id
GROUP BY facture_echeance_mois ORDER BY facture_echeance_mois
ASC, SUM(commande.montant) DESC;
Je n'ai des commandes qu'en mars, avril, juillet et août.
afin de générer un graphique avec les montants commandés par mois.
Pourriez vous m'aider à modifier ma requête afin d'obtenir les résultats
pour tous les mois de l'année.
J'aimerais que cela soit possible, cela m'éviterais de devoir ensuite
traiter les résultats avec php.
PS: Je dois garder ces deux tables distinctes (je n'ai pas mis tous
les champs de chacune de ces tables)
SQL ne saurait inventé des donnés qui n'existe pas dans votre système d'information. Or à la base ces dates n'existent probablement pas dans votre SI. Il y a là à l'évidence un défaut de votre modèle de données.
C'est bizarre, en survolant les requètes de l'OP, j'ai cru voir des extraction de mois sur un champ (probablement) de type 'date' dans la table facture. Il faut toujours lire les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Accessoirement, vous quotez comme un goret.
-- Avec les trucs (assembleurs, compilateurs, interpréteur) j'ai eu parfois l'impression de vouloir manipuler des billes avec des gants de boxe. Mais on se fait vite au confort! --{ fr.comp.ordinosaures }--
--{ Fred Brouard - SQLpro a plopé ceci: }--
SQL ne saurait inventé des donnés qui n'existe pas dans votre système
d'information. Or à la base ces dates n'existent probablement pas dans
votre SI. Il y a là à l'évidence un défaut de votre modèle de données.
C'est bizarre, en survolant les requètes de l'OP, j'ai cru
voir des extraction de mois sur un champ (probablement) de
type 'date' dans la table facture. Il faut toujours lire
les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Accessoirement, vous quotez comme un goret.
--
Avec les trucs (assembleurs, compilateurs, interpréteur) j'ai eu parfois
l'impression de vouloir manipuler des billes avec des gants de boxe.
Mais on se fait vite au confort!
--{ fr.comp.ordinosaures }--
SQL ne saurait inventé des donnés qui n'existe pas dans votre système d'information. Or à la base ces dates n'existent probablement pas dans votre SI. Il y a là à l'évidence un défaut de votre modèle de données.
C'est bizarre, en survolant les requètes de l'OP, j'ai cru voir des extraction de mois sur un champ (probablement) de type 'date' dans la table facture. Il faut toujours lire les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Accessoirement, vous quotez comme un goret.
-- Avec les trucs (assembleurs, compilateurs, interpréteur) j'ai eu parfois l'impression de vouloir manipuler des billes avec des gants de boxe. Mais on se fait vite au confort! --{ fr.comp.ordinosaures }--
nobody
Thierry B. a écrit :
--{ Fred Brouard - SQLpro a plopé ceci: }--
SQL ne saurait inventé des donnés qui n'existe pas dans votre système d'information. Or à la base ces dates n'existent probablement pas dans votre SI. Il y a là à l'évidence un défaut de votre modèle de données.
C'est bizarre, en survolant les requètes de l'OP, j'ai cru voir des extraction de mois sur un champ (probablement) de type 'date' dans la table facture. Il faut toujours lire les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Accessoirement, vous quotez comme un goret.
et si y avait que cela à lui reprocher ce ne serait rien ...... :-)
Thierry B. a écrit :
--{ Fred Brouard - SQLpro a plopé ceci: }--
SQL ne saurait inventé des donnés qui n'existe pas dans votre système
d'information. Or à la base ces dates n'existent probablement pas dans
votre SI. Il y a là à l'évidence un défaut de votre modèle de données.
C'est bizarre, en survolant les requètes de l'OP, j'ai cru
voir des extraction de mois sur un champ (probablement) de
type 'date' dans la table facture. Il faut toujours lire
les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Accessoirement, vous quotez comme un goret.
et si y avait que cela à lui reprocher ce ne serait rien ...... :-)
SQL ne saurait inventé des donnés qui n'existe pas dans votre système d'information. Or à la base ces dates n'existent probablement pas dans votre SI. Il y a là à l'évidence un défaut de votre modèle de données.
C'est bizarre, en survolant les requètes de l'OP, j'ai cru voir des extraction de mois sur un champ (probablement) de type 'date' dans la table facture. Il faut toujours lire les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Accessoirement, vous quotez comme un goret.
et si y avait que cela à lui reprocher ce ne serait rien ...... :-)
zebul0n
Thierry B. a écrit :
C'est bizarre, en survolant les requètes de l'OP, j'ai cru voir des extraction de mois sur un champ (probablement) de type 'date' dans la table facture. Il faut toujours lire les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Effectivement, le champ echeance est de type 'date', mais je ne comprends pas le sens de votre remarque. Pourriez vous être plus explicite ?
Cordialement.
Thierry B. a écrit :
C'est bizarre, en survolant les requètes de l'OP, j'ai cru
voir des extraction de mois sur un champ (probablement) de
type 'date' dans la table facture. Il faut toujours lire
les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Effectivement, le champ echeance est de type 'date', mais je ne comprends
pas le sens de votre remarque. Pourriez vous être plus explicite ?
C'est bizarre, en survolant les requètes de l'OP, j'ai cru voir des extraction de mois sur un champ (probablement) de type 'date' dans la table facture. Il faut toujours lire les posts en entier avant de troller.
SELECT SUM(commande.montant) ca, MONTH(facture.echeance)
Effectivement, le champ echeance est de type 'date', mais je ne comprends pas le sens de votre remarque. Pourriez vous être plus explicite ?
Cordialement.
Patrick Mevzek
Le Sat, 04 Aug 2007 23:12:01 +0000, zebul0n a écrit:
Pourriez vous m'aider à modifier ma requête afin d'obtenir les résultats pour tous les mois de l'année.
Une façon de faire, probablement pas la seule, et sûrement améliorable, qui fonctionne avec PostgreSQL, et devrait fonctionner aussi avec MySQL, dans une version suffisamment récente.
Soit __S__ votre requête initiale. Soit mois une table dans la base, avec un seul attribut mois, et 12 lignes, mois de 1 à 12.
La requête suivante donne la table comme vous le souhaitez : SELECT mois.mois,COALESCE(total.prix,0) FROM (__S__) AS total(mois,prix) RIGHT OUTER JOIN mois ON (total.mois=mois.mois);
Cela fonctionne aussi avec UNION, qui dédoublonne par défaut, mais cela part du principe que les doublons sont recherchés dans l'ordre d'écriture des tables dans la requête, je ne sais pas si c'est un postulat garanti.
SELECT * FROM (__S__) AS total(mois,prix) UNION SELECT mois,0 FROM mois;
On peut améliorer les choses en évitant la sous-requête sur __S__ en ré-ecrivant cette dernière, et en particulier en sortant le ORDER BY.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Sat, 04 Aug 2007 23:12:01 +0000, zebul0n a écrit:
Pourriez vous m'aider à modifier ma requête afin d'obtenir les résultats
pour tous les mois de l'année.
Une façon de faire, probablement pas la seule, et sûrement améliorable,
qui fonctionne avec PostgreSQL, et devrait fonctionner aussi avec MySQL,
dans une version suffisamment récente.
Soit __S__ votre requête initiale.
Soit mois une table dans la base, avec un seul attribut mois, et 12
lignes, mois de 1 à 12.
La requête suivante donne la table comme vous le souhaitez :
SELECT mois.mois,COALESCE(total.prix,0) FROM (__S__) AS
total(mois,prix) RIGHT OUTER JOIN mois ON (total.mois=mois.mois);
Cela fonctionne aussi avec UNION, qui dédoublonne par défaut, mais
cela part du principe que les doublons sont recherchés dans l'ordre
d'écriture des tables dans la requête, je ne sais pas si c'est un postulat
garanti.
SELECT * FROM (__S__) AS total(mois,prix) UNION SELECT mois,0 FROM mois;
On peut améliorer les choses en évitant la sous-requête sur __S__ en
ré-ecrivant cette dernière, et en particulier en sortant le ORDER BY.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Sat, 04 Aug 2007 23:12:01 +0000, zebul0n a écrit:
Pourriez vous m'aider à modifier ma requête afin d'obtenir les résultats pour tous les mois de l'année.
Une façon de faire, probablement pas la seule, et sûrement améliorable, qui fonctionne avec PostgreSQL, et devrait fonctionner aussi avec MySQL, dans une version suffisamment récente.
Soit __S__ votre requête initiale. Soit mois une table dans la base, avec un seul attribut mois, et 12 lignes, mois de 1 à 12.
La requête suivante donne la table comme vous le souhaitez : SELECT mois.mois,COALESCE(total.prix,0) FROM (__S__) AS total(mois,prix) RIGHT OUTER JOIN mois ON (total.mois=mois.mois);
Cela fonctionne aussi avec UNION, qui dédoublonne par défaut, mais cela part du principe que les doublons sont recherchés dans l'ordre d'écriture des tables dans la requête, je ne sais pas si c'est un postulat garanti.
SELECT * FROM (__S__) AS total(mois,prix) UNION SELECT mois,0 FROM mois;
On peut améliorer les choses en évitant la sous-requête sur __S__ en ré-ecrivant cette dernière, et en particulier en sortant le ORDER BY.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
