Discussion :

[nicowizzz]

Bonjour,

Je dois développez sur une page, un affichage de stock que je dois ensuite disposer par catégories dans différents blocs (CSS).

Je peux le réaliser très simplement en faisait 20 requêtes mysql dans la page où se trouve les différents blocs (j'ai 20 catégories différentes).

Je me suis dit que cela serait stupide et qu'en une seule requête je pourrais m'en sortir. J'ai donc essayé de tout stocker dans un tableau et de trier les résultats (avec l'aide d'un admin ici). Mais maintenant à par faire 20 conditions IF pour chaque bloc et afficher, je reviens un peu à la même conclusion.

C'est une BDD avec environ 30000 lignes, la requête va uniquement chercher maximum 60 lignes avec le where. Et j'ai juste 4/5 colonnes à récupérer.
Faire 20 requêtes pourrait le faire, mais auriez-vous une idée plus pro ?

Merci d'avance à vous

[_AlexL]

Hello,

Tu utilises un framework ? Quelque chose ?

le top du top serait de faire quelque chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
foreach($categories as $category) {
echo '<div>';
echo '<span>'.category->name.'</span>;
echo '<ul>';
foreach($category->getStock() as $stock) {
echo '<li>'.$stock->name.'</li>;
}
echo '</ul>';
echo '</div>';
}

Mais là tu referas tes 20 requêtes (dans le getStock)... J'pense que faire 20 requête c'est pas "grave" et avec ces 20 reqûetes ton code sera beaucoup plus lisible et maintenable (et facile à écrire) que si tu fais une grosse requête avec derrière un traitement lourds pour afficher la données...

En espérant t'avoir aidé ^^

AlexL

[zaza576]

Hello,

Je te recommande ceci :
- avoir une solution fonctionnelle sur un petit jeu de données
- détecter les goulots d'étranglement sur les performances lors d'un appel à la base et affichage dans le front (2 étapes) (voir onglet Réseau de Firebug)
- optimiser le code / revoir la stratégie d'appel / d'affichage pour accélérer le process.
- tester et corriger sur un jeu de données plus grand

Dans un premier temps, montre-nous ta requête ainsi que le schéma complet de ta base de données (tables, liens, ...).
On se posera les questions suivantes :
- Pouvons-nous améliorer / optimiser / simplifier la requête ?
- Combien de temps moyen nous prend t'elle ?
- Quel est l'avantage / le temps pris à gérer une requête globale ou plein de petites requêtes ?
- Sous quelle forme retournes-tu tes données du back-end au front-end ?
- Appliques-tu des traitements côté backend sur les données avant le retour au front end ?
- Appliques-tu des traitements côté frontend une fois les données obtenues pour l'affichage ?
- Respectes-tu les responsabilités de ton client, ton serveur et ta base ?

Revoir un peu la stratégie d'appel :
- faire un appel de méthode de ton frontend (interface graphique client web) vers ton backend PHP. Du genre getAllMyDatas()
- Côté PHP, développer ton getAllMyDatas() et effectuer :
-------- une unique requête SQL à ta base avec plein de jointures pour retourner les données sous forme d'un gros objet (JSON ?) que tu formateras côté front dans ton tableau HTML
-------- plein de petites requêtes SQL à ta base. Puis, tu construis un objet PHP unique avec tes données que tu retournes côté front (en JSON) pour formater dans ton tableau HTML

En gros, tu n'auras qu'un simple aller-retour de ton front-end à ton backend et une ou plusieurs connexions de ton backend à ta base SQL.

Essaies de découper les tâches et d'identifier ce qui te coûte en temps.
Si déjà tu récupères tes données non triées de ta base à ton front end, est-ce que tu peux pas gagner plus en perf ?
Ensuite, tu peux toujours reporter ton filtre / tri sur le frontend après avoir rappatrié tes données.

[rawsrc]

Salut,

poste le code de génération de la page en question