+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Architecture pas optimisée (/showthread.php?tid=7617)
RE: Architecture pas optimisée - Argorate - 06-04-2016
[HS]requete SQL dans du code? outch ça pique^^ Vive les ORM :p[/HS]
RE: Architecture pas optimisée - Xenos - 06-04-2016
Ce qui pique serait plutôt le fait de préparer la même requête dans la boucle. Préparer une requête, cela veut bien dire "la préparer", et après, tu l'exécutes avec les valeurs que tu veux. Donc, L'Omniscient, tu devrais sortir la requête à préparer de la boucle, pour la préparer en amont, et l'utiliser dans la boucle pour l'exécuter (oui, on peut aussi proxifier la requête à préparer pour éviter de préparer inutilement l'une des deux queries, mais dans tous les cas, préparer avant la boucle sera ici plus véloce que dans la boucle).
J'ai un peu survolé le problème (d'ailleurs, le forum est chiant avec les balises "code", car si le texte déborde, il ne revient pas à la ligne et faute de scrollbar, la fin du code n'est pas visible), mais il me semble que tu veux récupérer la liste de ressources d'une case (en gros). Alors, comme dit, pourquoi retourner 3x une ressource? Pourquoi ne pas créer un tableau PHP avec la liste des ressources de la case (façon id ressource => array(uinfos, genre, quantite, date, ou, autre)) et le retourner (en JSON par exemple) pour ensuite traiter ces 3 (ou N) ressources coté client?
(Si je suis à coté du problème, laissez tombez ce message)
RE: Architecture pas optimisée - niahoo - 06-04-2016
(déjà je me suis ajouté ce css personnalisé sur le forum :
code pre {
tab-size: 4;
-moz-tab-size: 4;
-o-tab-size: 4;
}, ça aide pas mal à la lecture.)
RE: Architecture pas optimisée - Xenos - 06-04-2016
(pas faux
var styles = document.createElement('style');
styles.appendChild(document.createTextNode('div > code > pre { overflow: scroll; }'));
document.head.appendChild(styles);
Parce que je n'ai pas stylish ici ^^)
RE: Architecture pas optimisée - niahoo - 06-04-2016
(et du coup j'ai mis overflow auto c'est plus sympa !)
voilà voilà, sinon toujours pas d'infos quant au fait de faire 3 allers-retours au lieu d'un en Ajax ?
RE: Architecture pas optimisée - L'Omniscient - 07-04-2016
Jt'ai filé un identifiant niahoo, ce sera plus parlant.
Mais tu m'as pas dis que l'aller client-AJAX était quasi immédiat, et que c'étaient les requêtes qui alourdissaient ?
Parce que si c'est le cas, ça ne sert à rien que je les rassemble.
Pour la présentation vu que j'ai peu de requêtes SQL et que c'est généralement dans des codes PHP courts, je trouve ça plus claires de les laisser avec le PHP. J'ai surtout beaucoup de fichiers JS, du coup je fais JS, "vue", récupération données PHP-SQL (à peu près).
Du coup Xenos, je dois préparer une requête INSERT, une requête UPDATE et je n'en choisis qu'une selon la condition ? Donc l'autre sera préparée même si elle n'est pas exécutée ? Ca va prendre du temps de chargement pour rien non ?
RE: Architecture pas optimisée - niahoo - 07-04-2016
Je ne crois pas avoir dit ça non, typiquement c'est les requêtes HTTP qui prennent le plus de temps, une petite requête SQL en local sur le serveur est très rapide.
Ensuite si tu fais des jointures de ouf sur 5 tables avec des millions d'enregistrement ça sera long c'est sur, et il faut optimiser tout ça, mais dans l'absolu tu auras besoin de ces données. Tandis que là tu n'as pas besoin de faire 3 aller-retours au lieu d'un seul, tu peux directement recoder ça.
RE: Architecture pas optimisée - Xenos - 07-04-2016
Actuellement, si j'ai bien suivi, ta boucle faire 3 tours, et prépare une requête INSERT ou UPDATE à chaque tour.
Donc préparer les 2 requêtes et les exécuter dans la boucle sera forcément plus véloce (dans le 1er cas, tu prépare toujours 3 trucs, dans le second, toujours 2, même s'il l'un des deux est inutile).
Si tu ne veux pas préparer une des deux requêtes inutilement, tu peux les proxifier (c'est là où l'OO devient intéressant).
class ProxyPrepare {
function __construct($pdo, $query) {
$this->query = $query;
$this->pdo = $pdo;
$this->prepared = null;
}
function getPrepared() {
if (!$this->prepared) {
$this->prepared = $this->pdo->prepare($this->query);
}
return $this->prepared;
}
}
//Usage
$update = new ProxyPrepare($myPdo, 'UPDATE... ? ...');
$insert = new ProxyPrepare($myPdo, 'INSERT... ? ...');
for (/*...*/) {
//...
if (/*...*/) {
$update->getPrepared()->exec(/*...*/);
}
else {
$insert->getPrepared()->exec(/*...*/);
}
}
Le principe étant alors d'instancier 2 objets (proxies) auxquels tu demandera la requête préparée, et qui ne la prépareront qu'une seule fois. Si la requête ne leur est jamais demandée, il ne la prépareront jamais.
Note que c'est une classe parfaitement réutilisable sur n'importe quelle requête à potentiellement préparer.
RE: Architecture pas optimisée - L'Omniscient - 07-04-2016
J'ai jamais fais de l'OO, mais merci pour ces exemples, ça va me permettre de mieux comprendre ^^
Bon du coup je vais faire 3 codes différents et tester les temps de chargement pour prendre le plus rapide ^^
RE: Architecture pas optimisée - L'Omniscient - 07-04-2016
Mais en fait niahoo, là on à quelque chose comme ça :
Seconde 1 : affichage - requête A 1s
Seconde 2 : affichage - requête B 1s
Seconde 3 : affichage - requête C 1s
Alors que tout sur une page ça ferait :
Seconde 1 : affichage
Seconde 2 : affichage
Seconde 3 : affichage requête A B C 2s
Seconde 4 : requête A B C 2s
En comptant 1 seconde en moins pour les 3 requête en 1 page parce que ça n'appelle la page des requête qu'une fois au lieu de trois.
Du coup, j'ai peur que ce soit plus long. Mais bon, j'essaie tout ça et je vous redis.