megarequête , sql et PHP

Version imprimable

23/05/2012, 13h47
redoran

megarequête , sql et PHP

Re; j'ai une requête qui affiche dans:
Première ligne du tableau:
extraction de l'année,
ensuite fait la somme des enregistrement de 18 colonnes pour une année XXXX,
ensuite fait la somme des colonnes impaires Total IP et colonnes paires Total P,
ensuite la somme de Total P et Total IP dans Total GL.
deuxième ligne du tableau:
pourcentage de chaque colonne par rapport au Total GL.
exemple :
DSG || cl1 ||cl2 ||cl3.........||cl18 ||Total IP||Total P||Total GL
AAA || 12 ||05 ||20..........||......|| 32 || 05 || 37
% || 32.43 ||13.51 ||.............||......|| 86.49 || 13.51 ||----

premièrement espérant que les développeur du site nous permettent d’insérer des tableaux. merci :mouarf:
ma question:
en matière d’optimisation avec un nombre conséquent d'enregistrements sous forme de chiffres.,
est il souhaitable de faire ce genre de mega requête sur le plan statistique bien sûr?
faire partagé les calcules entre mysql et PHP ?
23/05/2012, 13h49
stealth35

y'a cl1 cl2 cl3 jusqu’à cl18 ?
23/05/2012, 14h50
CinePhil

Les traitements de masse sont en principe plus rapides dans le SGBD qu'en PHP car un SGBD est fait pour ça.

Commence par montrer la requête que tu as faite.

Ceci dit, si tu as la possibilité de changer le modèle de données, ce serait souhaitable !

Re, Requête: c'est une bombe a gaz :calin:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
$cbd->exec("SET lc_time_names = 'fr_FR'");
    $tbord=$cbd->prepare('SELECT MONTHNAME(datedec)AS Mois ,MONTH(datedec)AS nummois, YEAR(datedec) AS an,
    sum(m)as m,sum(f)as f,sum(m1)as m1,sum(f1)as f1,sum(m2)as m2,sum(f2)as f2,sum(m3)as m3,sum(f3)as f3,sum(m4)as m4,sum(f4)as f4,
    sum(m5)as m5,sum(f5)as f5,sum(m6)as m6,sum(f6)as f6,sum(m7)as m7,sum(f7)as f7,sum(m8)as m8,sum(f8)as f8,
    (sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)) As Total_M ,
    (sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)) As Total_F ,
    (sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)) AS Total ,
 ROUND(((sum(m)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm,
									ROUND(((sum(f)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf,
									ROUND(((sum(m1)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm1,
									ROUND(((sum(f1)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf1,
									ROUND(((sum(m2)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm2,
									ROUND(((sum(f2)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf2,
									ROUND(((sum(m3)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm3,
									ROUND(((sum(f3)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf3,
									ROUND(((sum(m4)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm4,
									ROUND(((sum(f4)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf4,
									ROUND(((sum(m5)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm5,
									ROUND(((sum(f5)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf5,
									ROUND(((sum(m6)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm6,
									ROUND(((sum(f6)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf6,
									ROUND(((sum(m7)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm7,
									ROUND(((sum(f7)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf7,
									ROUND(((sum(m8)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pm8,
									ROUND(((sum(f8)*100)/((sum(m)+sum(m1)+sum(m2)+sum(m3)+sum(m4)+sum(m5)+sum(m6)+sum(m7)+sum(m8)+sum(f)+sum(f1)+sum(f2)+sum(f3)+sum(f4)+sum(f5)+sum(f6)+sum(f7)+sum(f8)))),2) AS pf8
 
 
 
FROM `conteneur` 
WHERE YEAR(datedec)=:an');
 
 
try {
	// On envois la requète
	$tbord->bindParam(':an', $_POST['an'] , PDO::PARAM_INT); 
	$tbord->execute();
	// On récupère en 1er toutes les données
	$datalist = $tbord->fetchAll(PDO::FETCH_ASSOC);
	// libèré la connexion du serveur
	$tbord->closeCursor();	
 
 
	}
catch( Exception $e ){
echo 'Erreur d\'affichage : ', $e->getMessage();
}
/*----------------- fin affichage */

désolé j'ai pas pu l’édenté sous l’éditeur de texte du forum :oops:

23/05/2012, 15h09
stealth35

c'est parce que ta table n'est pas correct mais je te l'avais déjà dis
23/05/2012, 15h44
redoran

Re; Stealth36 oui je me rappel bien est je té répondu que c'est suite a l’étude de l'existant et au exigence du propriétaire.
avec cette composition on évite de faire des PIVOTS et GROUP BY par paramètre A et paramètre B....
23/05/2012, 15h46
stealth35

c'est de la bidouille et du-coup tu vois bien que ça coince, tant que ta base ne sera pas correct ça ne marchera pas
23/05/2012, 16h19
redoran

Citation:

que ça coince

apparemment sa marche très bien , seulement ma question étais sur le plan optimisation est temps d’exécution par rapport a un nombre important d'enregistrements.
23/05/2012, 16h23
stealth35

Ca coince dans le sens ou tu ne pourras simplifié ta requête, et le serveur a mon avis doit en prendre un coup, elle met combien de temps la requête ?
23/05/2012, 16h33
redoran

sur phpMyadmin:
Affichage des lignes 0 - 0 ( 1 total, Traitement en 0.0150 sec) pour 22 enregistrements en local.
23/05/2012, 16h36
stealth35

bah ça va pourquoi tu veux optimiser ça

Juste un petit truc redoran, je me suis amusé à indenter le début de ta requête et tu as un niveau de parenthèses en trop il me semble dans le ROUND :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
SELECT MONTHNAME(datedec)AS Mois,
	MONTH(datedec)AS nummois, 
	YEAR(datedec) AS an,
    sum(m) as m, sum(f) as f, sum(m1) as m1, sum(f1) as f1, sum(m2) as m2, sum(f2) as f2, sum(m3) as m3, sum(f3) as f3, sum(m4) as m4, sum(f4)as f4,
    sum(m5) as m5, sum(f5) as f5, sum(m6) as m6, sum(f6) as f6, sum(m7) as m7, sum(f7) as f7, sum(m8) as m8, sum(f8)as f8,
    (
		sum(m) + sum(m1) + sum(m2) + sum(m3) + sum(m4) + sum(m5) + sum(m6) + sum(m7) + sum(m8)
	) As Total_M,
    (
		sum(f) + sum(f1) + sum(f2) + sum(f3) + sum(f4) + sum(f5) + sum(f6) + sum(f7) + sum(f8)
	) As Total_F,
    (
		sum(m) + sum(m1) + sum(m2)  +sum(m3) + sum(m4) + sum(m5) + sum(m6) + sum(m7) + sum(m8) 
			+ sum(f) + sum(f1) + sum(f2) + sum(f3) + sum(f4) + sum(f5) + sum(f6) + sum(f7) + sum(f8)
	) AS Total,
	ROUND
	(
		(
			(sum(m)*100) / 
			(
				(
					sum(m) + sum(m1) + sum(m2) + sum(m3) + sum(m4) + sum(m5) + sum(m6) + sum(m7) + sum(m8) + 
						sum(f) + sum(f1) + sum(f2) + sum(f3) + sum(f4) + sum(f5) + sum(f6) + sum(f7) + sum(f8)
				)
			)
		)
	,2) AS pm,

Au passage, remarque qu'elle pique un peu moins les yeux comme ça ta requête non ?

23/05/2012, 16h45
redoran

j'ai besoin d'un avis , j'ai l'habitude de faire ce type de requêtes en monposte [delphi+access] et sa marche bien.
en site web dynamique là je manque d'expérience. :oops:
quelque soit la requête , normalement les SGBDR ont un processus de traitement de requêtes c'est a dire la capacité de transformé la requête écrite en requête optimisée , si c'est le cas est ce que mysql possède ce processus et comment peut ont accédé a cette écriture?
23/05/2012, 16h49
stealth35

en faisant des sous requete ça doit le faire
23/05/2012, 16h52
redoran

Citation:

en faisant des sous requête ça doit le faire

, justement pour cela que je parle de transformation , parce que les SGBDR gèrent différemment les sous requêtes afin de réduire le temps de traitement.
23/05/2012, 16h54
stealth35

t'as moyen d'envoyer la table ça va être dur de tester sans
23/05/2012, 17h01
redoran

1 pièce(s) jointe(s)

la table conteneur Pièce jointe 95636
23/05/2012, 17h06
stealth35

le but final c'est de récupérer uniquement les moyennes ?

j'arrive à ça

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
SELECT 
    MONTHNAME(c.datedec) AS Mois ,
    MONTH(c.datedec)     AS nummois, 
    YEAR(c.datedec)      AS an,
    ROUND(((SUM(c.m)  * 100) / f.Total), 2) AS pm,
    ROUND(((SUM(c.m1) * 100) / f.Total), 2) AS pm1,
    ROUND(((SUM(c.m2) * 100) / f.Total), 2) AS pm2,
    ROUND(((SUM(c.m3) * 100) / f.Total), 2) AS pm3,
    ROUND(((SUM(c.m4) * 100) / f.Total), 2) AS pm4,
    ROUND(((SUM(c.m5) * 100) / f.Total), 2) AS pm5,
    ROUND(((SUM(c.m6) * 100) / f.Total), 2) AS pm6,
    ROUND(((SUM(c.m7) * 100) / f.Total), 2) AS pm7,
    ROUND(((SUM(c.m8) * 100) / f.Total), 2) AS pm8,
    ROUND(((SUM(c.f)  * 100) / f.Total), 2) AS pf,
    ROUND(((SUM(c.f1) * 100) / f.Total), 2) AS pf1,
    ROUND(((SUM(c.f2) * 100) / f.Total), 2) AS pf2,
    ROUND(((SUM(c.f3) * 100) / f.Total), 2) AS pf3,
    ROUND(((SUM(c.f4) * 100) / f.Total), 2) AS pf4,
    ROUND(((SUM(c.f5) * 100) / f.Total), 2) AS pf5,
    ROUND(((SUM(c.f6) * 100) / f.Total), 2) AS pf6,
    ROUND(((SUM(c.f7) * 100) / f.Total), 2) AS pf7,
    ROUND(((SUM(c.f8) * 100) / f.Total), 2) AS pf8
FROM `conteneur` c, (
    SELECT (Total_M + Total_F) AS Total FROM(
        SELECT  
            (m + m1 + m2 + m3 + m4 + m5 + m6 + m7 + m8) AS Total_M ,
            (f + f1 + f2 + f3 + f4 + f5 + f6 + f7 + f8) AS Total_F 
        FROM (
            SELECT
                SUM(m)  AS m,
                SUM(f)  AS f,
                SUM(m1) AS m1,
                SUM(f1) AS f1,
                SUM(m2) AS m2,
                SUM(f2) AS f2,
                SUM(m3) AS m3,
                SUM(f3) AS f3,
                SUM(m4) AS m4,
                SUM(f4) AS f4,
                SUM(m5) AS m5,
                SUM(f5) AS f5,
                SUM(m6) AS m6,
                SUM(f6) AS f6,
                SUM(m7) AS m7,
                SUM(f7) AS f7,
                SUM(m8) AS m8,
                SUM(f8) AS f8
            FROM `conteneur`
            ) c
        ) t 
    ) f

ps :
- sinon ton closeCursor sert a rien, un et fetch suffit
- y'a aucune logique (de nommage) entre Mois, nummois et an

23/05/2012, 23h49
redoran

RE, désolé pour le retard !! faute de connexion...
ta requête affiche seulement les pourcentage et fait:
Affichage des lignes 0 - 0 ( 1 total, Traitement en 0.0017 sec) plus rapide que la mienne :

Affichage des lignes 0 - 0 ( 1 total, Traitement en 0.0150 sec) pour 22 enregistrements en local.
mais ta pas l'affichage des sommes !!!!!
24/05/2012, 09h37
redoran
Salam ; ta raison y' a pas intérêt d'extraire le numéro du mois et le nom du mois c'est une omission de ma part.

Citation:

le but final c'est de récupérer uniquement les moyennes ?

non , c'est faire des sommes de chaque colonnes et les affichés ensuite calculé le pourcentage de la somme de chaque colonne par rapport au Total et les affichés au dessous des sommes précédemment calculées.
maintenant si je comprend le schéma d'exécution de ta requête sa donne ça:
1. calcul des sommes des colonnes,
2. calcul de la somme des sommes des colonnes,
3. calcul des pourcentage.
Elle est structurée par partie c'est un avantage.
est ce que MySQL est performant avec les sous-requêtes? là d'après la literature MYSQL ne gére pas bien les sous requêtes!!!!
mais le teste de ta requête et la mienne y'a une différence significative. :calim2:

comment peut on faire sous phMYadmin faire affiché le QEP de l'optimiseur pour voir comment il transforme les différentes requêtes? merci

si tu veux tout fais

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
SELECT 
    MONTHNAME(c.datedec) AS monthname,
    MONTH(c.datedec)     AS month, 
    YEAR(c.datedec)      AS an,
    ROUND(((f.m  * 100) / f.Total), 2) AS pm,
    ROUND(((f.m1 * 100) / f.Total), 2) AS pm1,
    ROUND(((f.m2 * 100) / f.Total), 2) AS pm2,
    ROUND(((f.m3 * 100) / f.Total), 2) AS pm3,
    ROUND(((f.m4 * 100) / f.Total), 2) AS pm4,
    ROUND(((f.m5 * 100) / f.Total), 2) AS pm5,
    ROUND(((f.m6 * 100) / f.Total), 2) AS pm6,
    ROUND(((f.m7 * 100) / f.Total), 2) AS pm7,
    ROUND(((f.m8 * 100) / f.Total), 2) AS pm8,
    ROUND(((f.f  * 100) / f.Total), 2) AS pf,
    ROUND(((f.f1 * 100) / f.Total), 2) AS pf1,
    ROUND(((f.f2 * 100) / f.Total), 2) AS pf2,
    ROUND(((f.f3 * 100) / f.Total), 2) AS pf3,
    ROUND(((f.f4 * 100) / f.Total), 2) AS pf4,
    ROUND(((f.f5 * 100) / f.Total), 2) AS pf5,
    ROUND(((f.f6 * 100) / f.Total), 2) AS pf6,
    ROUND(((f.f7 * 100) / f.Total), 2) AS pf7,
    ROUND(((f.f8 * 100) / f.Total), 2) AS pf8,
    f.*
FROM `conteneur` c, (
    SELECT 
        (Total_M + Total_F) AS Total, t.*
    FROM(
        SELECT  
            (m + m1 + m2 + m3 + m4 + m5 + m6 + m7 + m8) AS Total_M ,
            (f + f1 + f2 + f3 + f4 + f5 + f6 + f7 + f8) AS Total_F,
            c.*
        FROM (
            SELECT
                SUM(m)  AS m,
                SUM(f)  AS f,
                SUM(m1) AS m1,
                SUM(f1) AS f1,
                SUM(m2) AS m2,
                SUM(f2) AS f2,
                SUM(m3) AS m3,
                SUM(f3) AS f3,
                SUM(m4) AS m4,
                SUM(f4) AS f4,
                SUM(m5) AS m5,
                SUM(f5) AS f5,
                SUM(m6) AS m6,
                SUM(f6) AS f6,
                SUM(m7) AS m7,
                SUM(f7) AS f7,
                SUM(m8) AS m8,
                SUM(f8) AS f8
            FROM `conteneur`
            ) c
        ) t 
    ) f
WHERE YEAR(c.datedec) = 2011
LIMIT 1

24/05/2012, 12h46
redoran

Re;merci pour le tout fais ;)
lors de l'exécution de la requête du calcul via l'interface web de l'application , et son exécution directement sur phpMyadmin , y'a une différence dans le résultat du calcul des pourcentage : une différence entre 0.24 et - 0.30.
touts les calcules sont exécutés dans la requête c'est bizzares !!!!
les mêmes chiffres repris sur excel , le résultat est identique de ceux de l'interface web. ( une autre interrogation a creusée !!!).
maintenant devant cette situation qu'elle solution adoptée?
celle de stealth36 sachant que MYSQL gère mal les sous requêtes ou la mienne?
dans les deux cas :
comment amélioré le temps de calcul et de réponse ? :sm:
24/05/2012, 13h18
stealth35

de toute façon en gardant ta base comme ça tu peux difficilement optimisé plus, puisque chaque calcule est unique
24/05/2012, 13h34
redoran

Résumons:
SGBDR: MYSQL V 5.10.
Machine: PC de production.
exécution : en local
fin projet : le tout sur un serveur.
application:
Le faite d'avoir 16 colonnes dans la table principale sa répond au support utilisé.
Nombre d'utilisateur en moyenne 500.
Nombre d'enregistrements par utilisateur: 365.
.......ect
couche statistique:
requêtes préparées sous PDO.
type : agrégats.
requêtes d'agrégats paramétrés sur un ou 4 champs maximum:
groupement par:
année , mois , semaines , département et le global.
nombre d’exécution : selon le besoin de l'utilisateur.

optimisation:
en dehors des performances du serveur.
requête préparée fait gagné du temps.
le tout dans la requête et laissé l'optimiseur faire son travail là !!!!!?????
les sous requêtes ou requêtes imbriqués c'est du :massacre:

une petite réflexion par rapport au sujet , qu'elle solution adoptée pour les agrégats ?
y'a t il des OLAP gratuit qui peuvent s’intègré facilement ?
je ne sait quoi dire sauf proposition de votre part.
24/05/2012, 13h46
stealth35

ta requete préparée n'a aucune incidence, pusiqu'il y a qu'un seul paramètre et qui n'est même pas basé sur un Index, de plus par default avec PDo les requêtes préparés sont déactivés

Qu'est ce que tu voudrais de plus en performance, ta requete fais moins d'un dixième de seconde en quoi c'est un problème ?
24/05/2012, 13h52
redoran

Citation:

avec PDO les requêtes préparés sont désactivés

là je vous suit pas , selon la documentation j'ai pas vu ce passage , par contre toujours on a PDO associé au prépare.

Citation:

Qu'est ce que tu voudrais de plus en performance, ta requete fais moins d'un dixième de seconde en quoi c'est un problème ?

je cherche a apprendre les bonnes manières de manipulation et de traitement de données dont les agrégats , et mon exemple de projet est un exemple. :mrgreen:
24/05/2012, 13h59
stealth35

est ce que tu sais vraiment ce qu'est une requete préparée ?

si tu veux apprendre les bonne manière pour optimiser ta table commence par faire un vrai schéma.
24/05/2012, 14h08
CinePhil

Citation:

Le faite d'avoir 16 colonnes dans la table principale sa répond au support utilisé.

Il faut distinguer le "support utilisé" (formulaire de saisie ? fichier texte source de données ?) du modèle de données normalisé à implémenter en BDD.

Sans plus de précision sur ce que sont ces 16 colonnes réellement, difficile de savoir si c'est justifié ou non mais comme tu les additionnes, ça nous laisse à penser que c'est le même type de données et que ces 16 colonnes ne devraient en faire qu'une.

Les calculs de masse seraient probablement beaucoup plus performants ainsi, même si ça multiplie le nombre de lignes par 16.
24/05/2012, 14h17
redoran

comme son nom l'indique , elle s’exécute en deux temps pour la première fois ensuite c'est la deuxième phase qui importe dans l'optimisation ( trafic sreveur et évité les injections sql..).

Citation:

si tu veux apprendre les bonne manière pour optimiser ta table commence par faire un vrai schéma.

je travail avec la méthode MERISE , je fait de proposition de modélisation mais la décision revient au décideur.
faut s'adapter , Ok :zen:
24/05/2012, 14h20
CinePhil

Tant que "Môssieu le décideur" te paye le temps que tu passes à galérer sur ce modèle, tant mieux pour toi !
24/05/2012, 14h21
stealth35

Citation:

Envoyé par redoran

je travail avec la méthode MERISE , je fait de proposition de modélisation mais la décision revient au décideur.
faut s'adapter , Ok :zen:

Tu fais comme moi, tu l'envoie chié en disant que c'est naze, et tu lui montre qu'il a tout à gagné en faisant un vrai schema. Et qu'en attendant que le projet n'avance pas t'es payé.
24/05/2012, 14h39
redoran

tout a fait d'accord avec vous sur le plan modélisation. :ccool:
donc l'optimisation c'est une démarche qui commence par ce point ensuite y'a plusieurs points qui suit a savoir normalisation des requêtes..... je crois que le sujet est vaste ; pour avoir une idée j'ai trouvé ce modeste travail d'une équipe extraordinaire http://thecodingmachine.developpez.c...b/?page=page_5
:coucou:
24/05/2012, 15h56
CinePhil

Principes énoncés par l'article que tu cites :

Citation:

Les principales solutions d'optimisation consistent à réduire les coûts de lecture des tables MySQL. Trois types de solutions sont possibles :

optimiser la gestion des index ;
agréger des données ;
améliorer les requêtes.

L'auteur a oublié le premier :
Vérifiez que votre modèle de données est normalisé.

Il est dommage d'ailleurs qu'il aborde l'optimisation de la BDD seulement au chapitre 5 alors qu'il aurait pu commencer par là !

Dans une autre discussion, on m'a donné un lien vers un schéma de la BDD de Wordpress, pourtant très répandu CMS bénéficiant d'une large communauté de développeurs. Et bien chez Wordpress, comme chez Drupal et comme dans d'autres produits pourtant très répandus, le modèle de données est mauvais et peut expliquer des lenteurs que l'on peut observer en utilisant ces outils.
24/05/2012, 16h48
redoran

je vais faire une relecture de l'article du lien a tète reposée.
actuellement je fait tout sur Notepad++ aucun cms.....
si on comprend le schéma d'exécution du SGBDR et comment il gère les requêtes qui ne respect pas son algorithme sa aide dans la rédaction des requêtes non!!!!
24/05/2012, 16h50
stealth35

niveau optimisation on est bon, donc y'a rien d'autre a faire,
niveau trafique tes a qu'une requete, niveau injection pareil y'a null part ou en mettre c'est du SELECT, et t'as qu'un paramètres
y'a rien d'autre a faire
27/05/2012, 10h25
redoran

Salam ; Redoran:

Citation:

si on comprend le schéma d'exécution du SGBDR et comment il gère les requêtes qui ne respect pas son algorithme sa aide dans la rédaction des requêtes non!!!!

L’instruction EXPLAIN permet d'avoir un plan d’exécution de la dite requête sous forme de tableau montrant comment l'optimiseur va exécuté la requête.
l’intérêt de la question ?
avec une instruction SELECT le moteur de BDD doit analyser l'instruction afin de déterminer le chemin le plus court pour extraire les données et calculé les agrégats. vaut mieux faire une requête normalisée et laissé le reste au moteur que faire une requête tordue et donné du bolo au moteur BDD ! :aie: