Zend FR

Même si j'ai allégé le code au maximum, ca reste très lourd. Un objet pouvant avoir tout un tat de relations enfouies les unes dans les autres, un simple appel à un jeu de résultat peut envahir la base de données, car la logique SQL n'est pas manipulée, en d'autres termes, on ne fait pas de join(), mais bien d'autres requêtes.

Bonjour Julien,
Bravo pour l'article. Je voudrais revenir sur cette phrase qui le conclut. Pardon de quoter une phrase venant d'un autre site, je ne sais pas si ça se fait.

Je me suis retrouvé récemment dans un cas où j'utilisais la "logique sql" en lançant une requête contenant des joins, au moins 15. A cause des produits cartésiens liés aux relations n à n et 1 à n entre mon entité principale est les autres, je me retrouvais avec plus de 1000 enregistrements pour 1 seule entité principale.
Or pour utiliser ce jeu de résultats, il me fallait le parser pour l'ordonner dans un tableau imbriqué.

J'ai donc opté pour la solution que tu évoques, je lance plusieurs requêtes et construis mon résultat imbriqué directement avec les jeux d'enregistrements retournés, donc plusieurs requêtes mais un parsing minimal des résultats.

Tout est histoire de dosage, qu'est-qui est plus rapide ? Ta méthode est surement préférable dans certains cas à une seule requête utilisant des joins.

On peut en deuxième exercice, instaurer un "level", à savoir, je ne descends pas chercher des relations au dela de X niveaux

Le problème c'est que tu voudras peut-être un niveau X sur une branche et un niveau Y sur une autre branche, non ?
Peut-être, y-aurait-t-il moyen de passer en paramètres des "points d'arrêts" qui feraient référence à ta référenceMap qui stopperaient le traitement récursif quand il sont atteints. Bon, je dis ça c'est peut-être une connerie, je n'y ai pas trop réfléchi, ce qui est sûr c'est que je n'en mourrais pas

A bientôt,

fred

P.S : En fait, j'aurais dû poster ce message sur l'autre site, je m'aperçois qu'il est hors sujet ici...

Dernière modification par fred wolf (30-04-2007 12:52:38)

Mff.
Une jointure, si elle est correctement faite, avec les bons indexs où il faut, est toujours plus rapide que 2 ou plusieurs requêtes séparées.

Là dessus je suis d'accord, ce n'est pas tant le temps de réponse de la requête qui me gêne, c'est le traitement du jeu de résultat.

Dans l'exemple que je cite, je me retrouve avec un millier d'enregistrements pour une seule entité. Mais en l'état, je ne peux rien en faire, il faut que je traite ce résultat, non ?

En fait, l'idéal serait d'obtenir ce jeu de résultat déjà imbriqué (nested).

Ca m'intéresse d'avoir ton (votre) avis là-dessus. J ne me suis jamais penché sur les procédures stockées, serait-ce une solution ?

Fred

Dernière modification par fred wolf (02-05-2007 10:11:39)