Discussion :

[identifiant_bidon]

Bonjour à tous,

Je vais commencer à développer une application nécessitant une authentification. Lors du login, un certain nombre d'informations sont récupérées (une vingtaine) qui caractérisent l'utilisateur qui se connecte. Je garderai ces informations en session.

Ma question est la suivante. D'un point de vue client quelle est la solution la plus performante au niveau des temps d'accès :
- 1 grosse requêtes SELECT à jointure (3 tables seraient concernées) ?
- 3 requêtes SELECT distinctes (1 requête par table) ?
- 1 requête SELECT sur une table qui regrouperait 20 colonnes ?

Les informations sont du type : email, nom, prenom, sexe, pseudo, adresse, ville, pays, profession, ...
Il y aura à terme une très grosse volumétrie.

Merci

[aieeeuuuuu]

bonjour,

si le modèle est correct (ce que nous ne pouvons juger car vous ne l'avez pas communiqué), je miserai sur la solution 1 avec jointure.
Cela dit, je ne comprends pas la logique de la troisiéme solution par rapport aux deux premières, je reste donc sur une réponse générique.

dans tous les cas, le mieux c'est de tester, avec la volumétrie et répartition des données prévue à terme.

[SQLpro]

La 2 prendra plus de temps que la 1 du fait des 3 aller/retours entre client et serveur (à mon avis près de 3 fois plus) donc à abandonner.
La 3 prendra légèrement moins de temps, SI LE VOLUME DES DONNÉS RESTE FAIBLE... SI le volume augmente ou qu'il y a beaucoup de mises a jour sur ces tables, alors ce sera bien pire...

A +

[StringBuilder]

Le compromis pour la 3 serait éventuellement de passer par une vue, pourquoi pas matérialisée.

Reste que la 1 est la première à mettre en place : si vraiment c'est trop lent, vous pourrez toujours tenter la 3ème méthode... Mais faut pas vous attendre à un gain significatif (ni même mesurable).

PS : Pour la solution 2, selon le SGBD et le langage client, vous pouvez exécuter un "lot" de requête en un seul allez retour. Même si c'est, je pense, de loin la solution la pire, cette astuce permet de limiter les dégâts. Elle sert généralement quand on veut par exemple récupérer "d'un coup" une ligne de commande et les lignes associées : plutôt que de faire une jointure et avoir les données de l'entête dupliquée sur chaque ligne de la commande (ce qui peut être très pénalisant en terme de volume échangé sur le réseau), on peut exécuter le premier select sur l'entête et le second sur les lignes, le tout dans une unique "commande". .NET le permet par exemple avec la plupart des SGBD que j'ai pu utiliser (SQL Server et Oracle principalement).