C'est une erreur de penser cela car les perfs des sgbd dépendent de leurs plans d'executions. Un select colonne n'est pas plus rapide qu'un select * quand il n'est pas sur une colonne indexé.
On ne te parle pas de traitement de requête mais de transfert sgbd->php, de deux chose l'une :
- soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin -> overhead coûteux inutile.
- soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur -> overhead coûteux inutile.
Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).
En plus, si par exemple tu as une table utilisateur, utiliser des select précis sur les colonnes signifie que derrière tu vas avoir autant de méthodes que de select pour modifier ces colonnes.
Au final, tu vas avoir une quantité de code qui va croite à chaque fois que t apporteras des modifications à tes tables. Rajouter d'une méthode par exemple pour parametrer le login, le mail , le pass etc ... Au final, ton gain de performances sera à peine quantifiable, et par contre ton code sera tellement gros qu'il te sera de plus en plus difficile de le maintenir.
Gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)
PMO pourrait utiliser des select sur des colonnes mais ça n'a pas d'intérêt, étant donné qu'il te donne un objet qui représente une ligne de ta table, et tu peux à partir de cet objet filtrer ce que tu veux utiliser. Tout le select n'est donc pas renvoyé comme ça.
C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)
[^] # Re: Mmmm, voyons voir...
Posté par Anonyme . En réponse au journal PMO v 0.07 déjà. Évalué à 8.
On ne te parle pas de traitement de requête mais de transfert sgbd->php, de deux chose l'une :
- soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin -> overhead coûteux inutile.
- soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur -> overhead coûteux inutile.
Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).
En plus, si par exemple tu as une table utilisateur, utiliser des select précis sur les colonnes signifie que derrière tu vas avoir autant de méthodes que de select pour modifier ces colonnes.
Au final, tu vas avoir une quantité de code qui va croite à chaque fois que t apporteras des modifications à tes tables. Rajouter d'une méthode par exemple pour parametrer le login, le mail , le pass etc ... Au final, ton gain de performances sera à peine quantifiable, et par contre ton code sera tellement gros qu'il te sera de plus en plus difficile de le maintenir.
Gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)
PMO pourrait utiliser des select sur des colonnes mais ça n'a pas d'intérêt, étant donné qu'il te donne un objet qui représente une ligne de ta table, et tu peux à partir de cet objet filtrer ce que tu veux utiliser. Tout le select n'est donc pas renvoyé comme ça.
C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)