Discussion :

[Vrugar]

Bonjour à tous,

Je suis actuellement en train de développer mon site internet (PHP orienté objet), cependant je me pose une question sur l'optimisation de quelques requêtes...

En effet, j'ai conçu le système pour qu'une table dans ma base de données = une class PHP (ou presque toujours). Et tous les attributs d'une classe = champs de la table en question. Toutes mes classes PHP extends une classe Model.
Cette classe est capable d'exécuter des requêtes sur les différentes tables en fonction de la classe utilisée.

Je m'explique, je veux obtenir un membre dont je connais l'email (par exemple), alors je fais :

Code :

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

$membre = Membre::find(array('email'=>$email));

Et là j'ai bien mon objet membre chargé avec toutes les infos nécessaire.

Cependant dans ma méthode find() j'utilise le sélecteur "a.*".
Exemple concret :

Code :

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

SELECT a.* FROM membre AS a WHERE email = $email

Je sais que ce n'est pas terrible alors voici une solution alternative que j'ai en tête :
- parcourir tous les attributs de l'objet puis former ma requête en fonction des attributs :
Exemple concret :

Code :

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

SELECT a.id, a.email, etc... FROM membre AS a WHERE email = $email

Pour vous, quelle est la meilleur solution niveau performance ? D'un côté pas de traitement PHP mais un *, d'un autre côté un traitement PHP mais au moins on ne fait pas de *

J'ai lu que le * faisait en fait 2 requêtes, est-ce vrai ?

Merci d'avance pour votre aide et/ou vos conseils !

[Fred_34]

L'utilisation de * est à éviter car la plupart du temps on n'a pas besoin de toutes les colonnes d'une table.
C'est donc logiquement plus performant de sélectionner que quelques colonnes plutôt que toutes les colonnes.

Dans ton cas, tu veux récupérer toutes les colonnes. Se poser la question de savoir qui de MySQL ou de PHP va être une nanoseconde plus rapide me semble avoir peu d’intérêt.
Si tu es à ce niveau de performance, il va falloir que tu évalues le temps supplémentaires pour transmettre X octets de plus dans la requête qui contient toutes les colonnes, ou que dans ton exemple, tu ne demandes pas a.email car tu le connais puisqu'il est dans le WHERE...

Dans ton cas (Tu veux construire ton objet avec toutes les données d'une table) :
- Les requêtes sont plus simple à écrire si tu utilises *
- Si un objet php à une colonne de plus que ta table, le resultat ne contiendra pas cette colonne si tu utilises *, alors que si tu précises les colonnes tu auras une erreur
- Si un objet php à une colonne de moins que ta table, le resultat contiendra une colonne en trop si tu utilises *
- ???

En gros, décide en fonction de tes besoins...

[Vrugar]

L'intégrité des données (attributs en fonction des champs de la table et vis-versa) est testée à chaque grosse mise à jour via des tests unitaires donc pas de soucis de ce côté là.

Pour le moment je vais donc laisser le * et je verrais bien comment se comporte le site dans le temps.

Pour le a.email, je suis obligé de faire comme ça pour récupérer l'email et le stocker dans les attributs de l'objet.
Une fois ma requête effectuée, j'instancie mon objet avec le retour de la requête.

Code :

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

return new Membre($sql->fetch('assoc'))

[tse_jc]

Bonjour,

Peut-être vais-je m'attirer les foudres de certains en disant cela, mais une gestion objet d'une base de données, n'est pertinent, cohérent et performant QUE pour de l'administration de SGBDR et QUE dans un contexte LOCAL, et encore pas dans la façon dont vous le faites. Ces patterns de développement n'ont pas de légitimité dans un contexte client-serveur WEB.

Vous voulez de la performance? Pourquoi passer des semaines à développer du code pour que votre serveur PHP se substitue au SGBDR? alors que de toute manière pour avoir de la performance il faut

1) Réduire au strict minimum et nécessaire toute communication entre le client le serveur tiers et le SGBDR.
2) Avoir une base normalisée au min en 4FN
3) Avoir des processes et donc des requêtes optimisées spécifiquement pour le SGBDR utilisées.

Il y a plein d'autres choses à dire (la liste est plus longue), mais voilà pour l'essentiel.

Pourquoi donc disais-je passer autant de temps pour créer automatiquement des requêtes non optimisées, mais vraiment non opti, alors que de toute manière il faut les écrire? autant les mettre sur le SGBDR directement, et faire avec PHP ce pourquoi il est fait c'est à dire gérer les interactions utilisateurs avec l'applicatif et une partie du comportement de l'IHM. En faisant ainsi, croyez moi on a largement de quoi faire.

De plus faire un site ecommerce c'est donner des garanties de service à la clientèle et de temps de réponse. Etes vous de tête capable de quantifier les aller retours de communication de votre application? la réponse est non je suppose.. Comment à partir de là pouvez vous être certain d'une statitisque fiable autre qu'empirique de performance? Comment pouvez-vous dire "on verrra bien comment l'application va se comporter". Ceci est incompatible avec une qualité de service digne de ce nom.

Vous savez dores et déjà que vous allez aller dans le mur à plus ou moins moyen terme, ça par contre c'est 100% garanti.

++

[ericd69]

salut,

mêmes remarques...

je rajouterais la poo, c'est pas le signe d'un code optimisé du tout!!

c'est principalement fait pour générer du code modulaire et réutilisable pas pour être optimisé...

le truc que tu fait serait plus justifier dans le cadre d'une interface dont tu découvrirais les composant à la volée...

mais franchement est justifié de faire ce genre d'usine à gaz pour les traitement que tu fais?

petit rappel: php est un langage interprété, chaque fois que tu instancie une classe tu réinterprètes et exécute ensuite le code de son constructeur...
on est pas dans du c/c++ par exemple...
ça peut avoir un coté pratique bien que dangereux pour la maintenance car tu peux du coup enlever ou ajouter des méthodes ou propriétés dynamiquement...

[tse_jc]

c'est principalement fait pour générer du code modulaire et réutilisable pas pour être optimisé...

Moi je ne l'aurais pas dit comme ça, mais chacun sa façon de dire les choses

[Fred_34]

Peut-être vais-je m'attirer les foudres de certains en disant cela, mais une gestion objet d'une base de données, n'est pertinent, cohérent et performant QUE pour de l'administration de SGBDR et QUE dans un contexte LOCAL, et encore pas dans la façon dont vous le faites. Ces patterns de développement n'ont pas de légitimité dans un contexte client-serveur WEB.

Je veux bien vous croire, mais pour l'instant vos exemples ne m'ont pas convaincu.

Ce que j'en pense ( Jusqu'à ce que vous m'ayez prouvé le contraire...) :
La requête de Vrugar permet de récupérer un utilisateur en fonction de son identifiant (Email). Apres, je suppose que dans tout son code il utilise un objet utilisateur. Effectivement, il est obligé de récupérer toutes les colonnes, mais niveau performance, je pense que c'est peanuts par rapport à récupérer uniquement les colonnes nécessaires et l'avantage c'est qu'il n'aura plus à faire de requête sur cet utilisateur puisqu'il a déjà tout!
Personnellement, je n'arrive pas à comprendre comment faire plus performant...
De plus, avec sa méthode, il peut toujours avoir une base normalisée, dans ce cas, il faudra surement une classe PHP pour une vue. Les mises à jour/créations seront probablement plus compliquées, mais pas les lectures.

Pour résumer :

1) Réduire au strict minimum et nécessaire toute communication entre le client le serveur tiers et le SGBDR.

- Il a une seule requête

2) Avoir une base normalisée au min en 4FN

- Un objet =une vue devrait fonctionner.

3) Avoir des processes et donc des requêtes optimisées spécifiquement pour le SGBDR utilisées.

- La requête de sélection en fonction d'un index est optimisée dans tous les SGBDR


Donc, avec cette méthode, il a une application client-serveur relativement simple et il garde la puissance d'un SGBDR pour le reporting, maintenance etc...

Vous savez dores et déjà que vous allez aller dans le mur à plus ou moins moyen terme, ça par contre c'est 100% garanti.

Etant donné que mon application repose plus ou moins sur le même principe que Vrugar, je suis fortement intéressé par toutes les explications que vous pourrez fournir.

Merci.

[ericd69]

parlons preuves alors...

tu es d'accord que c'est la méthode find() de membre qui génère la requête...

qu'elle est appelée, à priori dans le constructeur, du moins, si tu lui passes un paramètre...

donc 1 instanciation de membre avec paramètre déclenche 1 requête!

si j'instancie 100 membres, 100 requêtes donc...

d'où la réflexion inverse à avoir si tu veux minimiser les échanges:

• je récupère toutes les données en une seule requête
• j'instancie les classes (si la poo se justifie) à partir des données

je rappelle qu'on parle d'optimisation...

ah oui et si tu argues que: "oui mais j'utilise des requêtes préparées donc j'optimise l'échange"...
hé bien non ça optimise rien... sauf à appeler la même requête plusieurs fois avec des paramètres différents avant de la désallouer...
hors si tu fais ça dans ta méthode find(), tu serais obliger de l'allouer et de la désallouer dedans (à moins d'être très ingénieux, ce n'est pas dur à faire mais il faut y penser)...

pour la bd, pour se prononcer faudrait la voir... après question optimisation pour des appels multiples tu as les procédures stockées...

voilà quelques idées