PHP|Débutant :: Forums

Saluton,
Bon, tu y étais "presque".
Tu conviendras aisément avec moi qu'une facture sans client n'a pas de raison d'être, donc la jointure externe vers la table fact_client doit être remplacée par une jointure interne.
Mais ce n'est pas ce qui empêche ta requête d'aboutir.
prixfacture est le résultat d'une fonction d'agrégation SUM dont le résultat ne peut être inféré dans la clause WHERE mais seulement après le GROUP BY.
Pour ce faire il existe une clause HAVING.

Ça devrait aller mieux comme cela.

Je reviens avec une autre question sur une requete similaire :

La requete fonctionne bien, cependant, j'aimerais afficher que les résultats qui pour date "date_send_fact" et "date_send_doc" vide
Facile me direz vous, mais non, car ces champs sont des la tables fact_suivi et il est possible qu'il n'existe pas... et si il n'y a pas d'enregistrement il ne me les affiches pas (alors que si ils sont vides ou inexistant, pour moi c'est la meme chose)

Une idée svp?
Merci
Yves

En fait c'est un table qui permet de faire le suivi d'une facture.
Elle contient des informations comme : date d'envoi de la facture, méthode d'envoi, a qui elle a été envoyé, date d'envoi du doc complémentaire, etc...
L'enregistrement correspondant a une facture n'existe qu'a partir du moment ou le membre a renseigné (via un formulaire) l'une de ses informations (cad qu'il a déja commencer a faire le suivi).
"date_send_fact" et "date_send_doc" sont au format varchar(10).
DOnc en faite, ce que je veux faire, c'est afficher un tableau qui contient les informations suivante :
numéro de facture, la date d'envoie de la facture, la date de payement (contenu dans la table facture donc pas de soucis) et la date d'envoi du doc

Mais si les 3 champs date contiennent qqchose (ce qui veut donc dire que le suivi est complet), il n'est pas necessaire d'afficher la ligne de la facture.
Est ce que je suis plus clair?
Merci

Humm tu me donnes des idées, faudrait tester.
Mais ce que je voulais faire, c'est lister toutes les factures pour lesquelles une ou plusieurs étapes n'avaient pas été faite et donc avoir une requete du genre :

Mais si la facture n'a pas d'enregistrement dans la table fact_suivi, ca ne me ressort rien du coup..

On en revient toujours au même, quand on est laxiste sur les processes d'entreprise, on en revient à perdre la consistence des données de l'entreprise, et c'est le début de la fin.
Les CMS ont encore de beaux jours devant eux, moi je vous l'dit !!!

Bonjour,

La première chose que j'allais te dire après avoir lu tes requêtes c'est qu'on a déjà évoqué ce problème dans ton premier post sur ce forum à savoir qu'il faut remettre la fonction d'agrégation dans le HAVING pour prixFacture au lieu de son alias. Mais lorsque tu dis

"On dirait que la requête boucle ce qui fait grimper la valeur de prixFacture", je ne suis plus certain de la nature de ton problème en fait.
Tu pourrais nous dire ce que tu obtiens concrètement et ce que tu devrais obtenir sur 1 ou 2 lignes d'exemple ?

De plus ton HAVING dans ta première requête ne corresponds pas au cahier des charges de ta requête.

En effet
1) f.montant_paye < prixFacture n'exclue pas le montant_paye =0 ce qui sort du contexte souhaité
2) le OR appliqué à la fois sur date_send_fact IS NULL OR date_send_doc IS_NULL non seulement n'exclue pas f.montant_paye=0 mais même si montant_paye=0 a été exclu dans la première condition, cette partie la rendrait à nouveau inclusive.
3) il te faudrait plutôt un

Tu remarqueras aussi le inférieur ou égal car la facture soldée rentre aussi dans le CDC que tu as exprimé, et normalement en n'oubliant pas de remplacer l'alias par la fonction d'agrégation.

Merci

Dernière modification par Jc (13-12-2012 05:26:52)

Bonsoir,

Je vais faire un petit rappel pour aide mémoire.

Quand le moteur de base de données doit parser la requête, il faut savoir que la clause SELECT est évaluée en dernier, et donc après les clauses FROM, WHERE, GROUP BY et HAVING (dans l'ordre). Ainsi les alias définis dans la clause SELECT sont inconnus au moment de l'évaluation des mêmes clauses.

Ensuite pour les alias je te recommande d'utiliser le mot clé AS systématiquement, car c'est une source d'erreur fréquente et difficile à déboguer surtout dans les requêtes complexes

Imagine par exemple que tu oublies une simple virgule en écrivant SELECT order_id order_date FROM orders ne retournera pas d'erreur mais order_date sera considéré comme un alias de order_id et donc une seule colonne sera affichée.

En plus je n'ai pas vérifié mais je crois que MySQL ne supporte pas l'absence de mot clé AS (l'ayant toujours mis en fait).

Pour ce qui est de l'obligation de répéter des formules un peu longues dans les clauses WHERE et HAVING, elles sont reconnues par l'optimiseur et sont évaluées qu'une seule fois contrairement à ce que l'on pourrait penser. Du moins sur SQL Server c'est certain à 100%, j'ai pas vérifié dans la doc MySQL^^.

Si tu veux éviter de te retaper 10 fois le calcul à la main dans ta requête, la solution peut être de créer une requête dérivée intégrant les calculs, ainsi il est possible d'y faire référence à l'extérieur via un alias (la clause FROM étant évaluée en premier).

Pour ton problème d'expression dans ton HAVING, excuse moi mais ton besoin précis ne m'apparaît pas clairement

Dernière modification par Jc (22-06-2013 17:18:47)

Oui comme ça je comprends mieux. En fait ton regroupement sur id_facture tu le fais sur la table fact_facture, alors que cette table n'est censée contenir qu'une seule référence à chaque facture, (ou une référence par paiement ?) si j'ai bien compris.
Tu as deux agrégations à faire, celle du calcul du montant de la facture dans la table fact_suivi qui je pense doit être faite dans une requête dérivée justement, et si tu as qu'une seule référence facture dans fact_facture alors tu reprends la même requête et ca doit être bon, sinon dans le cas où tu as une référence par paiement partiel, tu refais l'agrégation sur le montant payé dans ta requête principale.

Si c'est pas tout à fait ça et que ca ne te suffit pas, donne moi l'analyse fonctionnelle des tables et leur structure ca aidera

Dernière modification par Jc (14-12-2012 15:58:21)

Essaye ça pour voir.

PS: Encore une BD qui a été modélisée à l'arrache

Dernière modification par Jc (15-12-2012 00:29:26)

La ligne unique venait du MAX...
Mais du coup, en essayant de comprendre la pertinence de ton MAX, je pense qu'il va falloir faire une requête dérivée au niveau du suivi pour retomber sur nos pattes car cela sous entend qu'il y a plusieurs suivis pour une même facture avec des dates d'envoi différentes... D'où l'ajout ici du ORDER BY, mais cela ne suffira pas.
En plus tes CASE... WHEN sont peu pertinents un simple date_send suffit avec l'information du type pour gérer l'affichage.

sera plus pertinent et plus performant, sutout en MyISAM...

Dernière modification par Jc (15-12-2012 00:43:18)

Bonsoir,

Avant de te répondre sur ton dernier post, je vais te répondre concernant ta base de données

- Elle n'est pas normalisée 3FN minimum
- Elle est en MyISAM et donc les contraintes de clé étrangères sont inopérantes et les performances ne seront pas au rendez-vous, surtout que des indexs ont été oubliés de manière à les rendre efficaces et d'autant plus en MyISAM.
- Tes contraintes de domaine ne sont pas standardisées, ainsi on se retrouve par exemple avec un id_facture sur fact_facture défini en INT UNSIGNED NOT NULL et un id_facture en INT NOT NULL sur fact_prestation, rendant ainsi les jointures inopérantes (fulls scans en perspective), date en VARCHAR, etc...

Sinon c'est bien ce qu'il me semblait il va falloir passer par des requêtes dérivées pour gérer tes dates. Dis-moi, tu as un seul enregistrement par facture et par type de suivi dans la table fact_suivi? Je te pose la question quand même, car normalement la réponse devrait être non si ton MAX était pertinent, mais n'ayant aucune certitude...

Dernière modification par Jc (15-12-2012 01:24:55)

Bonjour,

C'est bien ce qui me semblait.
Tu es victime pour ta requête de ton absence de modélisation correcte car ta table suivi est redondante donc dénormalisée. Il ne faut pas confondre la gestion des statuts de tes factures, et la gestion des logs action sur les factures émises. Dans ta modélisation actuelle donc, quel est le critère qui doit être retenu en interne pour dire parmi x dates d'envoi quel est la date qui doit être considérée comme étant la date d'envoi officielle pour la facture? Si c'est la dernière, ton MAX est justifié, si c'est la première, ton MAX est faux. Si en interne il suffit de vérifier qu'une date d'envoi existe pour dire qu'elle a été envoyée, alors tu peux t'en sortir avec ta modélisation actuelle et adapter ta requête en conséquence. Sinon tu es dans une impasse fonctionnelle, sauf si c'est l'envoi à une personne particulière qui donne date certaine à l'envoi de la facture.

Bon week-end.

Dernière modification par Jc (15-12-2012 18:16:10)