Optimisation C# et Sql Server

Bonjour à tous,

Alors je me posais une question depuis pas mal de temps et finalement je ne suis pas sûr de la réponse.
J'ai par exemple dans une listview une liste de 2000 outils. Chaque outil possède ses propres caractéristiques, issues de différentes tables dans la base de données sql.
L'idée toute simple c'est d'afficher les données lorsque l'utilisateur clique sur un outil.
Alors voilà ma question : qu'est-il le plus judicieux à faire ?
-au chargement du formulaire, je fais des requêtes sql globales et je stocke les données dans des classes/variables/collections/dictionnaire, etc... et ensuite je fais l'extraction des données dont j'ai besoin par des recherches dans mes dictionnaires par exemple
-je ne fais rien au chargement, mais à chaque clic je fais une requête sql qui me sort mes données

Je n'ai pas l'habitude de grosses bases de données avec plein de tables et plein de valeurs, je ne sais donc pas si disons une requête sur 10 tables liées avec une condition issue d'une table de 500000 valeurs est instantanée. Je ne veux pas un avis d'un point de vue facilité de dev, propreté du code, mais purement optimisation. En gros qu'est-ce qui sera le plus performant, y a-t-il des good practices en la matière?

Merci d'avance

Bonjour,

Deux autres pistes :

1/ C# et SQL Server permettent de faire des curseurs persistants.
Ainsi, on peut populler un listview ou une gridview à partir d'une requête, tout en ne chargeant que les lignes affichées.
=> On gagne en temps de réponse, puisqu'on n'a pas besoin de charger toutes les lignes avant d'afficher le contrôle
=> On perds en réactivité lors du scroll, puisqu'on doit charger les données depuis la base à ce moment
Je n'ai pas d'exemple de code, j'avoue que c'est pas une méthode dont je sois très friand, car complexe à combiner avec la solution ci-après.

2/ Mise en cache progressive (et pourquoi pas asynchrone)
On charge uniquement les données de base dans la requête qui alimente la listview.
Puis on alimente des objets fils pour chaque lignes avec le détail, au fur et à mesure des accès aux lignes.
Éventuellement, en parallèle, on peut lancer, en asynchrone, une population de la liste avec les éléments complets, sans attendre les actions utilisateurs.

Sinon, selon si la connexion à la base est rapide ou non (serveur en local, réseau local, vpn, etc.) il vaut mieux réduire le nombre de requêtes au profit du volume de données retournées. Ne pas hésiter à faire 1 seule requête qui ramène tout, c'est à dire les données de base à afficher dans la liste, et les données complètes du détail.
=> Moins de charge de la base de données
=> Au final, moins de données échangées (on charge tout une fois plutôt que plein de trucs au fur et à mesure)
=> Meilleure montée en charge de la base de données (moins d'accès concurrents)

PS : Avant de mettre en place de telles solutions (attention aux problèmes de cache pas à jour suite à des modifications faites par un autre client) il faut surtout identifier l'origine des lenteurs. Souvent, il y a de quoi faire simplement en optimisant le modèle de données et les requêtes SQL, mais aussi les méthodes de chargement (1 grosse requête plutôt que N requêtes par exemple). C'est d'ailleurs à cause de ce dernier point que je déconseille comme la peste les couches d'abstraction de la base de données telles que NHibernate ou Link to SQL par exemple. Séduisant sur le papier, mais l'horreur en termes de performance dès qu'on sort du tutorial "hello world" sur une base avec 2 tables de 10 lignes.

tout dépend du contexte

quand il y a beaucoup de données ou un pc lent, charger tout au démarrage n'est pas faisable
néanmoins en terme de user friendly lui faire perdre moins de temps est utile, de plus de nos jours il y a beaucoup de ram sur les pcs, donc autant l'utiliser (10000 string de 50 caractère ca ne représente que moins d'1Mo)

donc en correlant la taille de ce que veux mettre en ram, le temps que ca prendrait, le temps que ca prendrait si on le faisait au moment du clic, et ce qu'on veut en terme de temps de réponse on peut alors prendre la décision

pour faire des mesures, il y a le system.Diagnostics.Stopwatch, on peut ainsi voir le temps d'exécution d'une requete, le temps de rapatriement des données etc...

faire des recherches sur une table de plusieurs millions de ligne peut etre instantané si le schéma de la base est correct (types des colonnes, indexes ...)
ce qui prend du temps en général c'est le rapatriement des données, remonter un million de lignes peut prendre quelques secondes

sinon dans le cas du chargement au clic tu peux faire une petite animation de chargement et charger sur un autre thread (ce qui ne bloque pas l'interface)

le mieux reste le plus complexe à coder, à savoir pour tous les items visible actuellement à l'écran plus x non visible en haut et en bas faire un chargement sur un autre thread des données dans des classes, au moment du clic tu peux alors afficher directement
par contre dans ce cas il ne faut pas charger les choses une par une, ca prend plus de temps qu'une requete par lot, c'est pour ca que je dis plus x en haut et x en bas
c'est par exemple ce que fait wpf sur les listbox, il créé les controles pour les éléments affichés, plus les les controles pour les x éléments précédents et suivant, en cas de défilement c'est rapide car les controles sont déjà créés
(de plus lui il recycle les controles, quand un controle devient invisible en haut il repasse en bas et contiendra d'autres données, mais ce n'est pas le sujet ^^)
après le mieux est l'ennemi du bien, si faire une requete au clic et très rapide, et à fortiori si l'utilisateur va faire peu de clic alors c'est dommage de perdre 30 heures à faire un truc complexe

Merci pour ces infos précises.
En fait c'est comme cela que j'ai toujours procédé, mais c'est vrai que c'est plus compliqué à gérer il me semble.
Dans mon cas précis, je vais donc faire un dictionnaire de classes, alimenté au chargement du form.
Restera à gérer les modifications des champs->update total de la listview ou seulement de la ligne concernée, on avisera :-)

Merci encore

Désolé, j'ai encore une question.
Sachant que pour l'affichage de la listview je vais proposer des filtres, n'aurais-je pas intérêt à stocker le résultat de ma requête dans un dataset pour ensuite alimenter mon dictionnaire et générer la listview à partir de ce dataset?

pour du post filtre oui avoir les données en ram est beaucoup mieux que de refaire une requete
et du coup tu peux rendre possible la possibilité de filtrer sur des sous propriétés qui ne sont affiché en détail que lorsqu'on sélectionne un élément

après le dataset je ne suis pas fan, c'est plus lent qu'autre chose
nous on a un list<object()> pour ce qui est issu de la requete, c'est performant (et plein de choses autour pour travailler dessus facilement)
enfin nous c'est un list<object()> car on ne s'embête pas à écrire du code identique plusieurs fois et on utilise donc un usercontrol avec des données différentes sur plusieurs fenêtres, sinon une classe convient mieux

et dans ce cas tu remplis ta listview tout simplement par foreach ?

oui
enfin nous c'est un datagrid, mais tout est dynamique

à savoir au passage, certains controles ont des méthodes beginupdate/endupdate
ces méthodes permettent de susprendre tout calcul et dessin du controle, permettant un gros gain de performance lors d'un ajout/modification multiple (idéalement dans un try finally)

Ok, merci pour tout