par
zeus » 08 avr. 2010, 14:15
@marwina32 : bon, alors le soucis se passe entre la récupération des données et la transmission au contrôleur.
Par contre, là, je seche un peu
La requête exécutée seule retourne des enregistrements, mais pas via Doctrine ...
Tu es sûre de l'exécuter sur la bonne base ?
@agité : je ne m'énerve pas, je met juste le doigts sur un point qui me parrait sensible dans notre échange, à savoir ne pas deviner entre les mots que je peux dire.
Alors, pour commencer, si tu as 300 requêtes sur une page, ORM ou pas, il y a une optimisation à faire, et c'est certainement dû à une jointure manquante. Et, toujours ORM ou pas, les jointures sont toujours un point à penser à l'avance, et il faut toujours garder un oeil sur l'évolution du nombre de requêtes sur une page.
Maintenant, mon propos est que
dans le cadre de l'utilisation d'un ORM, il vaut mieux faire des SELECT *, qui vont remplir correctement les objets, plutôt que des SELECT ciblé, qui vont remplir
partiellement les objets, et qui sera source d'erreur quand tu appelleras le getter d'un attribut non rempli. Dans l'optique objet d'un ORM, charger des demi-objets est très dangereux puisque tu n'es pas sensé savoir quels sont les attributs qui vont être affiché, ni comment.
Ceci dit, il est toujours possible d'exécuter quelques requêtes de manière "non objet" (comprendre retourner un tableau de données plutôt qu'un tableau d'objet) et c'est quelques fois bien pratique, pour des requêtes sensible à optimiser. Mais cette pratique doit rester annexe dans le cadre de l'utilisation d'un ORM. Sinon, il n'a plus d'intérêt, et il suffirait d'utiliser un DBAL à ce compte là.
@marwina32 : bon, alors le soucis se passe entre la récupération des données et la transmission au contrôleur.
Par contre, là, je seche un peu :-k
La requête exécutée seule retourne des enregistrements, mais pas via Doctrine ...
Tu es sûre de l'exécuter sur la bonne base ?
@agité : je ne m'énerve pas, je met juste le doigts sur un point qui me parrait sensible dans notre échange, à savoir ne pas deviner entre les mots que je peux dire.
Alors, pour commencer, si tu as 300 requêtes sur une page, ORM ou pas, il y a une optimisation à faire, et c'est certainement dû à une jointure manquante. Et, toujours ORM ou pas, les jointures sont toujours un point à penser à l'avance, et il faut toujours garder un oeil sur l'évolution du nombre de requêtes sur une page.
Maintenant, mon propos est que [b]dans le cadre de l'utilisation d'un ORM[/b], il vaut mieux faire des SELECT *, qui vont remplir correctement les objets, plutôt que des SELECT ciblé, qui vont remplir [u]partiellement[/u] les objets, et qui sera source d'erreur quand tu appelleras le getter d'un attribut non rempli. Dans l'optique objet d'un ORM, charger des demi-objets est très dangereux puisque tu n'es pas sensé savoir quels sont les attributs qui vont être affiché, ni comment.
Ceci dit, il est toujours possible d'exécuter quelques requêtes de manière "non objet" (comprendre retourner un tableau de données plutôt qu'un tableau d'objet) et c'est quelques fois bien pratique, pour des requêtes sensible à optimiser. Mais cette pratique doit rester annexe dans le cadre de l'utilisation d'un ORM. Sinon, il n'a plus d'intérêt, et il suffirait d'utiliser un DBAL à ce compte là.
