Merci pour ces chiffres, ça montre bien qu'il faut l'utiliser avec précaution... On 26/08/2014 16:09, Eric Chatellier wrote:
Bonjour,
Pour faire un retours sur la performance (ou non performance des fetch), voici quelque stats sur un cas rapide sur PostgresSQL, mais très lent sur Sql Server. Le problème de lenteur n'est pas le point ici, mais plutot le volume de données qui transit.
Pour la volumétrie de la requete, on a: - 1 Mail (23 champs) - 4 Pièces jointes (9 champs) - 56 Ligne d'historique (7 champs) - 11 autres entité de cardinalité 1 (EtatAttente, DemandStatus...)
La requete executée est la suivante: http://forge.codelutin.com/issues/5655#note-3 Elle retourne environ 224 lignes (soit le produit cartésien de 1 * 4 * 56)
L'ensemble des champs représente 131 colonne. Soit un ResultSet composé de 29344 élément. Donc 29344 pour afficher un seul élément.
À titre de comparaison, la même fonctionnalité en 3 requêtes aurait retourné 1 * 115 = 115 (email + relation 0..1 avec fetch) 4 * 9 = 36 (attachments) 56 * 7 = 392 (historique)
Soit un result set de 543 éléments, mais en 3 requetes.
Le produit cartésien augmente beaucoup la taille donc je me demande si c'est si performant que ca, ou que cela doit être nuancé par la volumétries des données.
Ne faudrait-il pas laisser les fetch pour les relations (0..1) et effectuer d'autres requetes pour les autres relations (2..*) ?