Quelle est la meilleure pratique de tri des données avec pagination, sur Business Tier ou Database Tier?

Question

Il pourrait être une question fréquemment posée, mais jusqu'à présent, je ne pouvais pas trouver une réponse convaincante.

Dans mon projet, j'ai besoin de faire de la pagination pour un ensemble de plus de 20 000 enregistrements, qui est un résultat joint de plusieurs tables, et qui doit être trié différemment selon les scénarios.

Actuellement, il y a 2 options devant moi:

1, faites-le en utilisant la procédure de magasin sur la base de données de niveau ie. where dl.[row_number] between @index*@size+1 and @index*@size+@size. Le problème de le faire est, vous devrez écrire des processus de magasin pour chaque tri séparément. , Faites-le sur le niveau Business Logic, et faites paginer et trier au-dessus du résultat. (ie. skip(), take()) Mais ce n'est pas idéal non plus, puisque vous pourriez finir par récupérer 20 000 enregistrements, mais seulement 10 d'entre eux sont utilisés

Y a-t-il une meilleure pratique standard disponible pour cela? merci d'avance

Answer 1

Gardez cette logique sur la couche de base de données.

si vous utilisez la procédure stockée, puis l'étendre pour inclure également la colonne de tri (s) afin que vous puissiez retourner le bon set

Answer 2

Si cela est une application multi-utilisateur, il y aura des problèmes d'évolutivité à moins que vous allez chercher le résultat pour une seule page d'affichage et valider la transaction. Par exemple, un affichage paginé sur un site Web doit effectuer une nouvelle requête chaque fois que l'utilisateur accède à la page suivante. L'alternative consiste à conserver le résultat complet de 20 Ko dans le contexte de la session Web, ce qui ne sera pas bien adapté.

Il existe un léger désagrément avec le langage SQL pour le tri, car le nom de colonne (ou l'index de colonne) pour le tri ne peut pas être paramétré.