Discussion :

[majduuus]

Bonjour,

Mon problème est que j'ai une table avec des millions de lignes et dés que j'éxécute une requête select le temps de réponse est trop lent. Celà peut prendre des minutes et des minutes. Je voulais savoir donc s'il y a une solution pour remédier à ce problème.

[fozzeuh]

Tu peux mettre des index et surtout filtrer pour avoir seulement les données que tu veux.

[majduuus]

Oui j'ai pensé à ça mais si j'ai besoin d'utiliser la requête select * from maTable sans filtrer les données y'a pas d'autres moyens?

[fozzeuh]

Pourquoi tu es obligé de faire ça ? tu veux savoir le nombre de ligne ?

[majduuus]

Dans mon appli je veux récupérer toute les données dans un tableau et après filtrer les données selon les critères de recherche

[fozzeuh]

Il vaut mieu que tu fasses une requête par type de tri que tu veux dans ton app

[majduuus]

D'accord je vais réfléchir dans ce sens là. Merci

[darkelend]

Il faut absolument filtrer les données dans la requête SQL ! Tu ne peux pas récupérer plusieurs millions de lignes en mémoire pour les filtrer ensuite. Tu consommerais de la RAM, des IO disques et du réseau pour rien.

[iberserk]

Ca n'a pas de sens, récupérer un million de ligne dans un tableau est stupide, aucune personne ne va parcourir votre tableau ...

Au minimum vous devez paginer vos données afin de n'afficher que les 20 premiers par exemple...

[mikedavem]

On se retrouve dans les problématiques du chuncky-chatty.

Je comprends que tu veuilles récupérer l'ensemble de tes données et filtrer par la suite au niveau du client. Le tri et la pagination côté client reste relativement simple via les contrôleurs built-in.

Le problème est que cette méthode n'est viable que si la quantité de données reste assez faible. Dès que tu dois charger une volumétrie importante on arrive vite aux limites de cette méthode :

- Chargement inutile de la mémoire côté SQL Server (potentielle contention mémoire + IO disques)
- Chargement important de la mémoire côté client ... il faut bien les stocker quelque part ses données ...

Comme te l'expliquent fozzeuh, darkelend et iberserk il vaut mieux faire du chatty ici et faire des petits chargements de données et introduire de la pagination côté SQL Server. C'est vrai que côté client cela demande un peu plus de travail mais c'est au prix des performances :-)

++

[iberserk]

C'est vrai que côté client cela demande un peu plus de travail

Avec du LINK TO ENTITIES ou LINQ TO SQL c'est même devenu d'une simplicité rare:
Par exemple pour avoir la page 2 d'un tableauavec 20 éléments par pages:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
MyLines.Skip(20).Take(20).ToList();

[majduuus]

Merci pour vos réponses. C'est sur ces idées là que je me suis basé.