megarequête , sql et PHP

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

---

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:

de toute façon en gardant ta base comme ça tu peux difficilement optimisé plus, puisque chaque calcule est unique

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.

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 ?

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:

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.

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.

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:

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

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é.

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:

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.

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!!!!

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

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: