Discussion :

[abbd]

Bonjour,

Je voudrai connaitre la limite d'une requête sur une BDD sql server, en effet, j'utilise Entity framework pour accéder à la BBDD en utilisant une interface .edmx, si ma base contient des millions d'enregistrements, est ce que je peux tout avoir avec seule requête, sinon est ce qu'il y a un axe d'optimisation ?

Merci d'avance de vos retour.

[DotNetMatt]

si ma base contient des millions d'enregistrements, est ce que je peux tout avoir avec seule requête, sinon est ce qu'il y a un axe d'optimisation ?

Bien sûr ! Il n'y a absolument aucun intérêt à ramener des millions d'enregistrements :
- Du point de vue de l'utilisateur, aucun (et je dis bien aucun) n'est capable ou n'a la volonté de consulter plusieurs millions d'enregistrements
- Du point de vue technique, à part créer des lenteurs, tu n'as aucun intérêt à faire ça.

Il existe des solutions :
- Pagination
- Aggrégation
...

[abbd]

Bien sûr ! Il n'y a absolument aucun intérêt à ramener des millions d'enregistrements :
- Du point de vue de l'utilisateur, aucun (et je dis bien aucun) n'est capable ou n'a la volonté de consulter plusieurs millions d'enregistrements
- Du point de vue technique, à part créer des lenteurs, tu n'as aucun intérêt à faire ça.

Il existe des solutions :
- Pagination
- Aggrégation
...

Effectivement, j'ai réalisé un exemple de pagination avec Take() et Skip(), cependant, comment les données sont organisées ?
par exemple on récupérer les 500 premiers puis les 500 seconds, si jamais il y a une ligne insérée, sa se passe comment ? on la récupérer dans la 3eme fois ?
Merci d'avance.

[DotNetMatt]

Les SGBDR reposent tous sur la théorie des ensembles. Cela signifie entre autre qu'il n'y a aucun ordre défini par défaut dans les tables. Tu peux trouver une démonstration très simple sur le blog de SQLPro : Les données d’une base SQL sont des ensembles…

Donc pour la pagination, il faut spécifier un ordre à l'aide de la clause ORDER BY. L'objectif étant d'avoir tout le temps le même tri appliqué au jeu de données lors de la pagination.

Concernant ta question sur la possibilité que des lignes soient insérées/modifiées/supprimées en cours de route, effectivement c'est possible. Soit tu l'acceptes et il pourra donc y avoir de temps en temps quelques décalages, soit tu peux insérer un "tampon" entre ce qui est en base et ce qui est affiché.

L'idée est par exemple lors de la première requête, de mettre en cache une partie des données (exemple la page 1 à la page 10). Une fois que c'est fait, tant que l'utilisateur sera dans cet intervalle, on ira récupérer les données depuis le cache, et non depuis la base de données. Lorsqu'il demande la page 11, on va récupérer les pages 11 à 20 pour les mettre en cache, et ainsi de suite.

Ca demande donc une mécanique supplémentaire, mais ça peut être utile si tu souhaites ne pas avoir de décalages dans la pagination en cours de route...