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

[Fred_34]

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

Rooh, tu exagères...
Une fois que tu as la méthode find() qui te retourne 1 objet, ça prends 2 minutes à faire une méthode qui te retourne une liste d'objets. (En une seule requête)

[ericd69]

je te prouve juste ce qu'on disait par rapport à ce qui est fait...

après sémantiquement si tu est dans un membre, ça parait peu logique de générer une liste de membres non?



bref, c'est une question d'approche et de logique...

les paradigmes objet ou procédural ne doivent simplement pas être des dogmes mais des outils...

enfin après chacun fait ce qu'il veut...

[tse_jc]

Bonjour,

Au delà de ce que viens d'exprimer ericd69, je vais essayer de développer un peu plus en détail, et recadrer un peu les choses si vous me le permettez, car il s'agit bien là d'optimisation et de conception dont on parle.

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.

déjà à partir de là, désolé de le dire fred, mais il ne s'agit pas là de mettre tout cela en place pour ne faire qu'UNE SEULE requête ni pour récuperer l'email d'UN SEUL utilisateur, on est bien d'accord, du moins je l'espère.

Ensuite hors d'un contexte d'aministration de SGBDR spécifique, expliquez moi l'intérêt de développer une classe objet / table si ce n'est pas pour faire de l'abstraction de base de données? A partir de là comment faites vous pour générer du code spécifique à chaque SGBDR et donc optimisé dans un tel contexte (en préservant l'abstraction et en répondant à tous les besoins de requête de l'applicatif)?

Contrairement à ce que vous avez dit, optimiser la performance ne consiste pas à savoir lequel du serveur tiers et plus rapide pour faire une tâche X que le SGBDR, car on connait déjà la réponse : le serveur le plus performant est celui qui a été conçu pour résoudre cette tâche à savoir le SGBDR pour les requêtes et donc du relationnel, et le serveur objet pour faire du calcul intensif. Cette considération résoud déjà 90% des cas de figure pour savoir quelle tâche effectuer sur quel serveur. Pour les 10% qui restent, on a la réponse quand on tient compte des contraintes physiques d'un contexte client serveur web, et que l'on veut minimiser les échanges pour diminuer les temps de réponse.

Ensuite,

Un objet =une vue devrait fonctionner.

Ah bon? quel intérêt de remodéliser quelque chose qui l'est déjà quand on parle de performance? Dans un contexte de vue utilisateur, si la requête ou la vue SQL est optimisée cela veut dire quoi? cela veut dire
1) qu'elle offre les meilleurs temps de réponse vis-à-vis du modèle applicatif normalisé
2) que sa signature corresponde exactement à ce qu'attends l'IHM de manière à ce que les données retournées nécessitent le moins de traitements possible.

A partir de là qu'à besoin de faire le serveur tiers si ce n'est transmettre le résultat de cette requête utilisateur directement et le plus rapidement possible? La réponse est simple: mettre en forme les résultats pour le rendu particulier attentu par l'IHM (date au format français sans l'heure, etc...). Donc pourquoi transformer systématiquement un resultset et donc l'array de données en classe objet PHP dans le contexte évoqué par vgrunt? alors qu'une simple mise en forme de valeur et une simple transformation en JSON pour le passer au navigateur suffit pour répondre au besoin?

L'idée conceptuelle est là.

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

ceci est vrai à partir du moment où le modèle est suffisamment normalisé, que la requête proposée offre un plan de requête optimisé pour le modèle et que l'index (ou les indexs) soit optimisé dans ce contexte.
Sinon faire de la persistance de classe dans une table avec un id autoincrémenté en clé primaire et baser sa requête dessus réponds à votre définition, or ce n'est pas vrai dans ce cas de figure.

Un objet=une vue devrait fonctionner

On est pas dans ce cas de figure (cf première citation de ce post), et je ne vois pas en quoi ceci viens faire en réponse à "une base normalisée en 4FN".

Effectivement, il est obligé de récupérer toutes les colonnes,...

Je ne vois pas en quoi il y a une telle obligation dans un contexte client serveur web. La seule obligation réelle du serveur tiers vis à vis du client dans un contexte performant est de lui fournir les informations demandées et pas plus. Toute autre action supplémentaire constitue une consommation inutile de ressources.
A partir de là, pour la performance au niveau conceptuel, c'est de ne pas faire transiter via le réseau des données inutilement, et de faire en sorte que chaque intervenant tiers au SGBDR (le client - le serveur tiers) ne demande à l'autre des données qu'il connait déjà.

Je ne pense pas après vous avoir lu, que votre application répondre à ce cahier des charges qui est pourtant fondamental dans un contexte client-serveur WEB performant.

++

[Fred_34]

Au delà de ce que viens d'exprimer ericd69, je vais essayer de développer un peu plus en détail, et recadrer un peu les choses si vous me le permettez, car il s'agit bien là d'optimisation et de conception dont on parle.

C'était le but de ma question, donc je te remercie d'avoir pris le temps d'y répondre. J'aimerai juste éclaircir les deux trois points ou j'ai encore des doutes.

Ensuite hors d'un contexte d'aministration de SGBDR spécifique, expliquez moi l'intérêt de développer une classe objet / table si ce n'est pas pour faire de l'abstraction de base de données? A partir de là comment faites vous pour générer du code spécifique à chaque SGBDR et donc optimisé dans un tel contexte (en préservant l'abstraction et en répondant à tous les besoins de requête de l'applicatif)?

Admettons qu'on ai envie d'utiliser MySQL et Oracle.
Avec deux objets MySQL et Oracle qui héritent d'une classe SGBD on devrait s'en sortir non ?

- Un objet =une vue devrait fonctionner.

On est pas dans ce cas de figure (cf première citation de ce post), et je ne vois pas en quoi ceci viens faire en réponse à "une base normalisée en 4FN".

Effectivement, je me suis surement enflammé avec la 4FN...
Je vais essayer d'expliquer ce que j'ai voulu dire.
Imaginons qu'un membre appartienne à un groupe.
Il peut avoir une classe Membre, deux tables (utilisateur et groupe) et une vue (membre)
C'est pas de la 4FN mais avec un peu de chance c'est de la 3FN ? (Faut que j'aille lire des cours...)

La seule obligation réelle du serveur tiers vis à vis du client dans un contexte performant est de lui fournir les informations demandées et pas plus. Toute autre action supplémentaire constitue une consommation inutile de ressources.

Sur la théorie on est d'accord.
Mais en pratique, je pense qu'en moyenne, il est plus performant de faire une requête qui va récupérer des données inutiles plutôt que de temps en temps être obligé de refaire une requête car on n'a pas ce qu'il faut.
Dans un post précédant vous parliez d'analyse de charge/performance. Dans le cas ou il y aurait 100 connexions simultanées, il me semble plus simple d'estimer 100 "grosses" requêtes plutôt que 100 "petites" requêtes + X autres "petites" requêtes en fonction de ce que va faire l'utilisateur.
Ou pas...

[tse_jc]

Re

Admettons qu'on ai envie d'utiliser MySQL et Oracle.
Avec deux objets MySQL et Oracle qui héritent d'une classe SGBD on devrait s'en sortir non ?

Avant de répondre et pour être certain (au cas où) rappel du contexte:

Ensuite hors d'un contexte d'aministration de SGBDR spécifique, expliquez moi l'intérêt de développer une classe objet / table si ce n'est pas pour faire de l'abstraction de base de données? A partir de là comment faites vous pour générer du code spécifique à chaque SGBDR et donc optimisé dans un tel contexte (en préservant l'abstraction et en répondant à tous les besoins de requête de l'applicatif)?

Faisons un peu de pratique: Prenons le cas d'une "petite" application avec disons 100 tables. Savez-vous en moyenne mini combien de requêtes opti sont nécessaires pour la faire fonctionner hors backoffice? je vais vous le dire environ 1300, ce qui fait une moyenne mini (mais vraiment mini) de 13 requêtes par table dans un contexte où aucun contexte d'appel applicatif ne peut être connu à l'avance quand on se place au niveau de la classe qui gère la table.
Donc la réponse est définitivement non! on ne peut pas s'en sortir dans le contexte evoqué juste au dessus et quand on se place dans votre approche des choses.
En effet si on veut sortir de ce carcan conceptuel d'un objet par table pour résoudre l'opti d'exploitation par sgbdr, une possibilité serait de commencer à penser process vertical, mais c'est un autre débat.

Sur la théorie on est d'accord.
Mais en pratique, je pense qu'en moyenne, il est plus performant de faire une requête qui va récupérer des données inutiles plutôt que de temps en temps être obligé de refaire une requête car on n'a pas ce qu'il faut.
Dans un post précédant vous parliez d'analyse de charge/performance. Dans le cas ou il y aurait 100 connexions simultanées, il me semble plus simple d'estimer 100 "grosses" requêtes plutôt que 100 "petites" requêtes + X autres "petites" requêtes en fonction de ce que va faire l'utilisateur.
Ou pas...

Alors là, pardonnez moi, mais faut bien le dire c'est très limite....
Je développe.
Tous ceux qui developpent ainsi, ont vraiment pas de figure de faire la morale à un débutant qui ose faire un SELECT * FROM dans ses requêtes, et j'assume ce que je dit. Pourquoi tant qu'on y est ne pas charger 20% ou + de la bd en cache sur une simple connexion utilisateur, juste au cas où? S'il reste 2min connecté pour vérifier le statut de sa commande vous avez l'air fin... si vous n'êtes pas tout simplement viré pour stresser inutilement votre serveur et avoir fortement diminué sa capacité de montée en charge.

On a suffisamment d'obligations quand on développe pour s'en rajouter des inutiles. Dans les obligations on a par exemple rappatrier des données contextuelles absoluement nécessaires en plus de celles demandées.
A ce propos quand je dis éviter de demander des informations que l'on connait déjà c'est aussi être capable d'aller chercher les informations demandées dans les informations contextuelles déjà rapatriées, et croyez moi celles-ci elles sont négligées dans plus de 95% des cas.

Je ne voudrais pas me faire de la pub, mais j'affirme qu'il est possible de mettre en pratique cette théorie qui ne semble être pour vous que de la théorie, et cela constitue même une partie de ma valeur ajoutée et je sais de quoi je parle. Seulement il faut sortir des patterns opti language compilé et application locale qui datent de l'an pépin qui restent pertinent mais pas dans un contexte client serveur web, et prendre le temps de penser différemment.

++

[tse_jc]

Juste une piste de reflexion.

Que penseriez-vous des deux statistiques suivantes sur une période X de temps:

1) Charge serveur Apache/PHP traitement requêtes données : 80% - %données fournies au client 40%
2) et une autre stat 80%-70%.

Je pense qu'il est pas besoin de sortir de saint-cyr pour avoir une idée pertinente sur la réponse. Or le premier "taux de conversion" est en général essentiellement dû à l'effet "grosse requête".

++

[ericd69]

pour l'utilisation de l'héritage, c'est en effet un des buts de la poo...

c'est même typique une des 2 façon d'utiliser pdo de manière avancée:

• soit tu en hérites pour l'étendre...
• soit tu fais comme moi je préfère faire, tu l'encapsules dans un objet, ce qui évite de laisser les méthodes de pdo accessibles et ne présenter que les méthodes de ton objet

ça tout à fait l'exemple typique ou la poo est utile...

mais tout transformer en objet n'est pas forcément utile... un exemple les session php... elles ne peuvent être encapsulées dans un objet en garantissant qu'un appel procédural (avec l'api des sessions) à celui-ci ne va interagir sur celles-ci...

pour les requêtes, là tu peux demander à qui tu veux tu es dans le faut de croire que * n'a qu'un cout très faible...
ça dépend implicitement de 3 choses:

• le fait que la connexion au sgbd est via tcp/ip en général donc plus tu as de trucs à bufferiser plus ça prends de ressources coté langage appelant et SGBD et plus tu risques des paquets en erreur ou perdus (en fonction de la QoS de la connexion) et sur des petites requêtes tu risque des temps de transmission parfois du même ordre que le temps d'exécution de celle-ci.
• c'est directement proportionnel à la taille d'une ligne de données (imagine par exemple plusieurs chaines de caractères bufferisées pour rien)
• coté ressources php retournées par la requête tu as là aussi une consommation de mémoire et de processeurs pour rien (car en plus, si tu génères un double tableau, un pour la version index numérique, un pour la version index associatif, sur tu ne forces pas l'un ou l'autre)

en terme de maintenance, le pauvre petit gars qui passera derrière toi je le plains pour comprendre ce que tu rapatrie... c'est aussi pour ça que c'est une pratique idiote

[SQLpro]

Moi, je me marre toujours dans ce forum, qui est ma grande rigolade matinale...
notamment à lire les élucubrations farfelues des incultes des SGBDR, qui posent des questions intéressantes et affirment ensuite des stupidités et qui veulent en plus donner des leçons sur le sujet !!!!

Hélas, la culture SGBD Relationnel à vraiment du mal à passer...

À me lire : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

A +

[Fred_34]

Jean-Christophe et Éric, merci pour vos explications.
Je ne suis pas encore complètement convaincu, mais plutôt que de continuer cette discussion et d'attirer des kktd aux propos désobligeants, je préfère en rester là pour le moment.
Laissons faire le temps et l’expérience pour le reste...