Discussion :

[guillaumeIOB]

donc quelques chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$sql_0 = "SELECT 
   SUM(D.fact_montant_final) as com_A, 
   SUM(D.frmd_mt) as com_B, 
   SUM(D.immo_frais_courtage) as com_C, 
   SUM(D.fact_commission_banque) as com_D, 
   SUM(D.fact_retrocommission) as com_E, 
   SUM(D.fact_commission_nette) as com_F 
 
   FROM `".$sufftable."dem` D
   INNER JOIN `".$sufftable."dem_gestion` G
      ON D.idCLIENT =G.idCLIENT 
   INNER JOIN `".$suff_table."dem_gestion` G
      ON D.idCLIENT =G.idCLIENT 
   INNER JOIN `".$suff_table."dem_pro` P
      ON D.idCLIENT =P.idCLIENT 
   INNER JOIN `".$suff_table."dem_immo` I
      ON D.idCLIENT =I.idCLIENT 
  WHERE ";

Mais j'ai un doute pour la jointure :

Code :

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

`".$sufftable."utilisateur` U  dont la jointure doit etre faite entre U.idUT=G.idGEST

car la requete indique les jonctions a partir de `".$sufftable."dem` D or `".$sufftable."utilisateur` U n'a pas de idCLIENT mais une jonction unique avec la table dem_gestion



et enfin il faudra bien une requete pour chaque execution d'un SUM ,

[Invité]

Code :

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

1
2
3
4
   INNER JOIN `".$sufftable."dem_gestion` G
      ON D.idCLIENT =G.idCLIENT 
   INNER JOIN `".$suff_table."dem_gestion` G
      ON D.idCLIENT =G.idCLIENT

Tu as mis 2 fois le même, ou tu as vraiment 2 variables $sufftable et $suff_table ??

Car alors, tu as VRAIMENT un GROS problème de NOMMAGE de tes variables !
Bonjour la confusion !!

Et tu ne peux pas mettre le MEME ALIAS "G" !

Code :

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

...utilisateur` U... ...mais une jonction unique avec la table dem_gestion...

Oui, ça suffit pour relier la table utilisateur aux autres.

[guillaumeIOB]

c est une erreur de copier coller.

Donc en résumé cela donnera ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$sql_0 = "SELECT 
   SUM(D.fact_montant_final) as com_A, 
   SUM(D.frmd_mt) as com_B, 
   SUM(D.immo_frais_courtage) as com_C, 
   SUM(D.fact_commission_banque) as com_D, 
   SUM(D.fact_retrocommission) as com_E, 
   SUM(D.fact_commission_nette) as com_F 
 
   FROM `".$sufftable."dem` D
   INNER JOIN `".$sufftable."dem_pro` P
      ON D.idCLIENT =P.idCLIENT 
   INNER JOIN `".$sufftable."dem_immo` I
      ON D.idCLIENT =I.idCLIENT 
   INNER JOIN `".$sufftable."dem_gestion` G
      ON D.idCLIENT =G.idCLIENT 
   INNER JOIN `".$sufftable."utilisateurs` U
      ON G.idGEST =U.idUT 
  WHERE ";

et par contre j'ai bien mes requetes suivantes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$totMT_1 = mysql_result($sql_0 , 0, 'com_A');
   $totMT_1= number_format($totMT_1, 2, ',', ' '); 
 
$totfrmt = mysql_result($sql_0 , 0, 'com_B') + mysql_result($resql_0 _4, 0, 'com_C');
   $totfrmt= number_format($totfrmt, 2, ',', ' '); 
 
$totcomretro = mysql_result($sql_0 , 0, 'com_D');
   $totcomretro= number_format($totcomretro, 2, ',', ' '); 
 
$totcomnette = mysql_result($sql_0, 0, 'com_E');
   $totcomnette= number_format($totcomnette, 2, ',', ' '); 
 
$totcombq = mysql_result($sql_0 , 0, 'com_F');
   $totcombq= number_format($totcombq, 2, ',', ' ');

Conclusion cela permet une lecture du code beaucoup plus simple et propre (ce qui est deja immense) mais pas encore une optimisation question ressources, puisque il me faut quand meme execute une requete par calcul de SUM, si j'ai bien compris ?

Merci

[Celira]

Conclusion cela permet une lecture du code beaucoup plus simple et propre (ce qui est deja immense) mais pas encore une optimisation question ressources, puisque il me faut quand meme execute une requete par calcul de SUM, si j'ai bien compris ?

Merci

Euh... mysql_result c'est pas une exécution, c'est une récupération de résultat. Donc tu exécutes une fois la requête et tu peux récupérer toutes tes sommes d'un coup à partir du même résultat. Tu fais 6 fois moins de requête, c'est déjà pas mal.

Dans ton fichier d'origine, le code s'arrête au niveau de la 1ere boucle :

Code :

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

1
2
3
4
5
while($cl = mysql_fetch_array($res, MYSQL_ASSOC))
        {
 	       $idcl =$cl['idCLIENT'];
           echo /////etc.....
        }

Ce serait p'tet une bonne idée de nous dire ce que fait le "//etc"

[Invité]

Bon.

Mets de l'ordre dans ta tête, et PRENDS LE TEMPS de t'organiser.

On ne peut pas te parler EN MÊME TEMPS de :

• l'optimisation SQL
• du traitement en PHP (que ce soit avec mysql_ ou PDO)

...Mais j'ai un doute pour la jointure...

On en reparlera quand tu auras des CERTITUDES.

[Invité]

J'en reviens à ce que j'ai conseillé tantôt :

il va falloir mettre TON code de coté, pour faire des EXERCICES (simples), afin de BIEN COMPRENDRE LA SYNTAXE PDO.
Notamment, la notion de requête préparée.

J'ajoute qu'il faut que tu te DOCUMENTES sur la BONNE UTILISATION / CONFIGURATION / SYNTAXE des tables et requêtes SQL :

• JOINTURE, différence entre INNER JOIN et LEFT JOIN,...
• PRIMARY / FOREIGN KEY
• colonnes indexées

Quand tu en sauras plus (par une RECHERCHE PERSONNELLE), tu comprendras mieux les conseils qu'on te donne.

[Dendrite]

Côté modélisation, il est clair qu'il y a tout à revoir...

On est au coeur de ta problématique. Je te donne juste un exemple pour que tu comprennes que tu ne peux pas laisser ta non-modélisation actuelle :

Dans ta table demandeur, te voilà à nous parler de... dossiers...

Es-tu bien sûr qu'un demandeur ne peut pas avoir plusieurs dossiers au cours de sa vie ?
Si oui, on parle bien de personnnes surendettées qui peuvent revenir plusieurs fois vers vous, ne serait-ce pas plus sage d'avoir

table demandeur (id, civ, nom, prenom, date_naissance, pays_naissance, ville_naissance) //des trucs qui ne bougent pas trop souvent globalement donc pas de dates associées

Clé d'unicité ? dans un monde idéal et si tu as le droit de le stocker... le numéro de sécu que tu mettrais après l'id auto increment... sinon, les 6 derniers champs
mais tu auras des problèmes de doublon, surtout avec des étrangers qui se nommeraient "chen li" nés à Pékin un 01/01/1970, parce que l'émigration a mis une date de naissance au pif...

Après je suppose que tu t'intéresses à la situation du foyer, qui peut aller de 1 (le demandeur, à n)
Mettons que le champ relation (avec le demandeur) soit un enum du type ('demandeur', 'conjoint', 'enfant', 'parent', 'autre')
D'où tu tiens qu'on n'a jamais vu une personne avoir plus de dix enfants ? Mon beau-père en a 14 !!!
Donc bien entendu qu'il faut procéder "dans l'autre sens"...
Les novices en modélisation ont tendance à tout vouloir mettre sur un seul plan immédiatement compréhensible.
Avec des floppées de colonnes... or, non, c'est une requête bien construite qui renvoie les colonnes bien jointes.

table foyer (id, demandeur_id, relation, civ, nom, prenom, naissance, debut, fin)//ah vi, un foyer, c'est vivant, les gens entrent et sortent. Pour toutes ces histoires de date, de bornage, il y a plusieurs politiques.
Mode facile : tu mets par défaut la fin à l'an 3000... avec un peu de chance, on sera tous morts, mais ça te permet de requêter directement avec des filtres comme "where curdate() between debut and fin"
Mode puriste : tu mets par défaut la fin à null... ce qui fait que toutes tes requêtes ont pour filtre temporel "where (fin is null or curdate() between debut and fin)"... plus lourd, mais plus juste.

Ensuite tu t'intéresseras aux revenus du foyer avec un truc du genre

table revenu(id, foyer_id, libelle, montant, debut, fin)//mettons les adultes du foyer et leur revenu mensuel (là aussi, évolutions constnates, donc bornage des dates)

idem pour les charges

table charge(id, foyer_id, libelle, montant, debut, fin)//mettons les adultes et les enfants du foyer et leurs charges mensuelles (évolutions possibles, fin de crédit etc.)

etc. etc.

On te laisse déjà étudier tout ça... Une application de gestion budgétaire est un excellent exercice pour comprendre les grands concepts de la modélisation.

[guillaumeIOB]

Merci a tous les deux pour votre aide précieuse

jreaux62 .. je vais m'atteler a tout regarder d'abord concernant le code PHP et effectivement je regarderai après l'optimisation.


Celira : ... je ne savais si la suite du code avait une importance puisque seulement la récupération de valeur, mais voici le code :

Code :

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

Merci encore pour tous vos conseils

[guillaumeIOB]

Côté modélisation, il est clair qu'il y a tout à revoir...
...

AIEEEEE!! tu ne sais pas a quel point tu souleves un probleme connu. Il m'a été demandé au moins une centaine de fois de pouvoir creer autant de dossier différents par personne, et comme je n'ai jamais eu le temps car j'ai une autre activité, je n'ai rien trouvé de mieux que de proposer de dupliqué une ligne client en 'NOMCLIENT_2' et donc un autre ID pour le meme client, ce qui m'a posé d'inombrables problemes comme par exemple le stockage de documents que je fais sur un disque dur dont l'url contient un hash sur la base de certaines informations du clients ...... qui sont evidemment les memes quand je duplique..;

Bref je sais que je dois tout reprendre, mais a la base ce logiciel n'avait pas une grande ambition et le voila utilisé (gratuitement) a plus de 20 agences qui sont toutes liées à l'association ....

[Invité]

Tu sais ce qui te reste à faire....


Du coup, PDO passe effectivement au second plan.

[guillaumeIOB]

Je sais ce qui me reste à faire dans l'avenir mais pas dans l'immédiat.

Je profiterai de la fermeture des asso en fin d'année pour recréer une architecture qui correspond a nos échanges, et leur fournir a la rentrée 2020 un autre logiciel, mais dans l'immédiat il faut que je solutionne les problemes rencontrés par ceux qui l'utilisent actuellement, car le fichier liste.php met des fois 5 minutes avant de s'ouvrir quand il ne s'ouvre pas avec un joli timout a l'ecran.

Donc je reste toujours ouvert sur ma problématique actuelle.

Merci de votre aide.

[guillaumeIOB]

Re,


J'ai retravaillé mon code pour le rendre plus propre, mais les SUM retournent une valeur a 0 alors que sur phpmyadmin j ai bien des lignes compétées qui apparaissent:

Code :

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

avec un echo sur $sql_sum

Code :

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

SELECT SUM(D.fact_montant_final) as com_fact_montant_final, SUM(D.frmd_mt) as com_frmd_mt, SUM(I.immo_frais_courtage) as com_immo_frais_courtage, SUM(D.fact_commission_banque) as com_fact_commission_banque, SUM(D.fact_retrocommission) as com_fact_retrocommission, SUM(D.fact_commission_nette) as com_fact_commission_nette FROM `extratest_dem` D INNER JOIN `extratest_dem_pro` P ON D.idCLIENT =P.idCLIENT INNER JOIN `extratest_dem_immo` I ON D.idCLIENT =I.idCLIENT INNER JOIN `extratest_dem_gestion` G ON D.idCLIENT =G.idCLIENT INNER JOIN `extratest_utilisateur` U ON G.idGEST =U.idUT WHERE (D.suivi='d_b_termine' or D.etude='d_b_termine') and D.nom_e LIKE '%' and (D.date>'1554069600' or D.datemodif>'1554069600') and D.supp='0' GROUP by D.idCLIENT

Merci de votre aide

[Dendrite]

Bon effectivement, j'entends tes arguments.
Mais prends garde à ne pas finir par fournir des données complètement fantaisistes à des associations et des usagers qui comptent sur ça pour vivre...

Alors, pour tes sum qui retournent 0...
Tu es bien sûr que tes requêtes précédentes, avant les sum, retournent bien plein de trucs ?

Car il faut d'abord vérifier que ce ne sont pas tes jointures qui te font des farces. Après tout, ce sont tes premières jointures.

Ensuite, quand tu as vérifié cela, il faut savoir ceci

SUM(ma_table.ma_colonne) retourne zéro si tu as un seul NULL dans tes valeurs...


Il faut donc écrire SUM(IFNULL(0,ma_table.ma_colonne)) as total
qui se traduira par : si valeur null alors ajoute 0, sinon ajoute valeur...
Mais ça aurait pu se régler aussi plus proprement (pour la prochaine fois) en posant dans ta table que tu n'autorises pas les NULL et que tu mets 0 par défaut.

A part ça, tu as un peu une idée des différences entre INNER JOIN et LEFT JOIN ? Ca a beaucoup d'importance, et il faut que tu te sortes un peu la tête de ton guidon.

[guillaumeIOB]

Merci dentrite pour ces infos.


Tout d'abord toutes les valeurs sont a 0 dans ma base, car INT (11) ou DECIMAL (10,2)

Il me semble que LEFT ne retourne que les resultat de la premiere table en gros et right que la seconde dans le cas ou il y a deux tables par exemple.

J'ai tenté de comprendre ça :

[Dendrite]

Respire un grand coup et médite sur ce dessin.

[guillaumeIOB]

Je viens de lire ça https://www.journaldunet.fr/web-tech...et-outer-join/

qui explique le retour d'une valeur null selon le choix de la jointure, mais je ne comprends pas l'interet autre que INNER voir LEFT dans mon cas.

EDIT :

du coté de PHPMYADMIN j'ai ça :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SELECT 
    SUM(D.fact_montant_final)     AS com_fact_montant_final, 
    SUM(D.frmd_mt)                AS com_frmd_mt, 
    SUM(I.immo_frais_courtage)    AS com_immo_frais_courtage, 
    SUM(D.fact_commission_banque) AS com_fact_commission_banque, 
    SUM(D.fact_retrocommission)   AS com_fact_retrocommission, 
    SUM(D.fact_commission_nette)  AS com_fact_commission_nette 
FROM 
    `extratest_dem` D 
        LEFT JOIN `extratest_dem_pro`     P ON D.idCLIENT = P.idCLIENT 
        LEFT JOIN `extratest_dem_immo`    I ON D.idCLIENT = I.idCLIENT 
        LEFT JOIN `extratest_dem_gestion` G ON D.idCLIENT = G.idCLIENT 
        LEFT JOIN `extratest_utilisateur` U ON G.idGEST   = U.idUT 
WHERE 
    (D.suivi = 'd_b_termine' OR D.etude = 'd_b_termine') 
    AND D.nom_e LIKE '%' 
    AND (D.date > '1554069600' OR D.datemodif > '1554069600') 
    AND D.supp = '0' 
GROUP by 
    D.idCLIENT

com_fact_montant_final      com_frmd_mt     com_immo_frais_courtage     com_fact_commission_banque      com_fact_retrocommission        com_fact_commission_nette
    260000.00                   0                   7000.00                     3000.00                         2000.00                         8000.00
         0.00                2000                      0.00                        0.00                            0.00                            0.00
         0.00                4000                      0.00                        0.00                            0.00                            0.00

Resultat idem avec INNER
Donc je ne comprends pas pourquoi j'ai un retour a 0

[Dendrite]

Mais ne va pas chercher des trucs trop abstraits.

Dis-toi plutôt ça :

J'ai une table demandeur(id, civ, nom, prenom, naissance)

J'ai une table enfant (id, demandeur_id, genre, nom, prenom, naissance)

J'ai une table demande (id, demandeur_id, dossier_num)

Quelle requête feras-tu pour me faire remonter toutes les informations utiles, en PARTANT de la base demande, et en utilisant TOUTES les infos de tes tables... (important de bien choisir sa table d'attaque).

Code SQL :

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

1
2
3
4
5
SELECT d.id as demande_id, dd.id as demandeur_id,dd.civ as demandeur_civ, dd.nom as demandeur_nom, dd.prenom as demandeur_prenom, TIMESTAMPDIFF (YEAR, dd.naissance, CURDATE()) as demandeur_age, GROUP_CONCAT( CONCAT(e.nom,' ',e.prenom,' 'TIMESTAMPDIFF (YEAR, e.naissance, CURDATE()) ) SEPARATOR ' / ' )) as enfants, d.dossier_num
FROM demande d
INNER JOIN demandeur dd on d.demandeur_id=dd.id
LEFT JOIN enfant e on e.demandeur_id=dd.id
GROUP BY d.id

Sauf erreur, ce truc te donnera un retour clair du genre
1542, 221, 'M', 'DUPONT', 'Marc', 45, 'Elsa DUPONT 5 / Samuel DUPONT 3', 345
1543, 54, 'Mme', 'DUBREUIL', 'Jeannine', 93, NULL, 345

Si tu mettais tout en INNER JOIN, Mme Dubreuil, sans enfants, disparaitraît de ta liste, ce que tu ne souhaites pas.

[Invité]

• Avec INNER JOIN, il faut NÉCESSAIREMENT un lien entre les 2 tables A et B.
• Avec LEFT JOIN, ça renvoie les résultats de la table A, même s'il n'y a pas de lien avec la table B, ET AUSSI ce de la table B SI il y a un lien.

[guillaumeIOB]

• Avec INNER JOIN, il faut NÉCESSAIREMENT un lien entre les 2 tables A et B.
• Avec LEFT JOIN, ça renvoie les résultats de la table A, même s'il n'y a pas de lien avec la table B, ET AUSSI ce de la table B SI il y a un lien.

ça j'avais bien compris ...

[guillaumeIOB]

@Dendrite

La je suis largué complet.. j'ai du atteindre les limites de mon cerveau............

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SELECT 
    D.urldossier, D.fact_retrocommission, D.fact_commission_banque, D.fact_commission_nette,
    I.projet_nat, I.projet_log, D.idAPP, D.idNOT, D.idRECOCL, D.cp,D.email, D.etude, D.suivi, 
    D.etude_A, D.suivi_A, D.traitement, D.idCLIENT, D.internet_date_A, D.internet, D.date, 
    D.datemodif, D.dateA, D.supp, D.ope_dossier, D.log, D.endet_av, D.fact_montant_final, 
    G.idGEST, U.idUT, D.frmd_mt, rav_av, pro_select_1, pro_select_2, pro_select_3, 
    pro_endetap_1, pro_restavap_1, pro_nombanque_1, pro_endetap_2, pro_restavap_2, 
    pro_nombanque_2, pro_endetap_3, pro_restavap_3, pro_nombanque_3, D.nom_e, D.prenom_e, 
    D.nom_c, D.prenom_c, D.tel, D.port, D.note_etoile, I.txz_dept, I.immo_frais_courtage 
 FROM 
    `extratest_dem` D 
        INNER JOIN `extratest_dem_pro`     P ON D.idCLIENT = P.idCLIENT 
        INNER JOIN `extratest_dem_immo`    I ON D.idCLIENT = I.idCLIENT 
        INNER JOIN `extratest_dem_gestion` G ON D.idCLIENT = G.idCLIENT 
            INNER JOIN `extratest_utilisateur` U ON G.idGEST   = U.idUT 
 WHERE 
    (D.suivi='d_b_termine' OR D.etude='d_b_termine') 
    AND D.nom_e LIKE '%' 
    AND (D.date>'1554069600' OR D.datemodif>'1554069600') 
    ABD D.supp = '0'

m'a bien renvoyé les resultats attendues en matiere de ligne demandeur

C'est uniquement avec SUM que ça bloque : retour a 0 malgré que les infos soit > 0

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SELECT 
    SUM(D.fact_montant_final)       AS com_fact_montant_final, 
    SUM(D.frmd_mt)                  AS com_frmd_mt, 
    SUM(I.immo_frais_courtage)      AS com_immo_frais_courtage, 
    SUM(D.fact_commission_banque)   AS com_fact_commission_banque, 
    SUM(D.fact_retrocommission)     AS com_fact_retrocommission, 
    SUM(D.fact_commission_nette)    AS com_fact_commission_nette 
FROM 
    `extratest_dem` D 
        INNER JOIN `extratest_dem_pro`     P ON D.idCLIENT = P.idCLIENT 
        INNER JOIN `extratest_dem_immo`    I ON D.idCLIENT = I.idCLIENT 
        INNER JOIN `extratest_dem_gestion` G ON D.idCLIENT = G.idCLIENT 
            INNER JOIN `extratest_utilisateur` U ON G.idGEST   = U.idUT 
WHERE 
    (D.suivi='d_b_termine' OR D.etude='d_b_termine') 
    AND D.nom_e LIKE '%' 
    AND (D.date>'1554069600' OR D.datemodif>'1554069600') 
    AND D.supp = '0' 
GROUP by 
    D.idCLIENT

com_fact_montant_final      com_frmd_mt     com_immo_frais_courtage     com_fact_commission_banque      com_fact_retrocommission        com_fact_commission_nette
    260000.00                   0                   7000.00                     3000.00                         2000.00                         8000.00
         0.00                2000                      0.00                        0.00                            0.00                            0.00
         0.00                4000                      0.00                        0.00                            0.00                            0.00