Partager via

Comportements de pagination et ordre

  • Article

Lors de l’interrogation de données à l’aide de FetchXML, les résultats de la requête de pagination peuvent faciliter l’affichage de grands volumes d’informations. Lors de l’utilisation de la pagination, il est important d’inclure également les paramètres de commande. Sans un ordre approprié, les demandes de pagination pour les « 50 prochains » enregistrements peuvent entraîner la récupération des mêmes enregistrements sur plusieurs pages, ce qui rend les révisions et les modifications beaucoup plus difficiles. Un bon classement des pages nécessite d’inclure des valeurs uniques pour aider à identifier les enregistrements inclus dans une page.

Pagination héritée

La pagination héritée dans Microsoft Dataverse charge tous les résultats de la requête jusqu’à la page actuelle en mémoire sur le serveur, sélectionne le nombre d’enregistrements nécessaires pour la page et ignore le reste. Cela présente des avantages tels qu’une pagination rapide en arrière/en avant dans les données ou le passage à une page spécifique, mais cela comporte également des restrictions telles qu’une limite de 50 000 lignes, des problèmes de performances avec de grandes requêtes complexes et des résultats de requête distincts triés de manière arbitraire.

Lors de la pagination avec classement, un cache des résultats de la page précédente est stocké dans un cookie de pagination. Cela permet de calculer ce que la page de données suivante doit afficher.

Si un utilisateur ne spécifie aucun paramètre « classer par », le système insérera automatiquement « classer par »<<entity name>>«.<<entityId>> asc »pour fournir un ordre de base. En fonction des données interrogées, cela peut entraîner des résultats inadéquats et inattendus car un seul utilisateur système peut être associé à plusieurs enregistrements dans n’importe quelle requête.

Si des FetchXML requêtes distinctes sont utilisées, le système n’ajoutera aucun ordre supplémentaire en raison des impacts potentiels sur les données renvoyées. Dans ces cas, les utilisateurs devront ajouter au moins une valeur de classement unique pour une expérience de pagination plus cohérente.

Notes

La pagination à l’aide de FetchXML for Dataverse est dynamique. La page sur laquelle un enregistrement apparaît est déterminée au moment où chaque page est rendue. Si 1 000 enregistrements sont affichés 50 par page, les 50 premiers enregistrements sont affichés en tant que page. Lorsque la page deux est demandée, le système détermine quels devraient être les 50 enregistrements suivants au moment de la demande. Pour cette raison, il ne serait pas possible d’utiliser la nouvelle fonctionnalité de pagination pour la pagination arrière. Le comportement hérité est utilisé pour la pagination arrière qui aura des performances réduites et tout retour après la page 500 ne peut pas être « repaginé » en raison des limitations héritées. 

Pourquoi est-ce important de classer ?

Si une requête est exécutée pour récupérer tous les enregistrements avec un état « Ouvert », cela peut entraîner 1 000 retours. Lors de la pagination de la page un à la page deux, le système n’a aucun moyen de savoir quelles commandes afficher à la page deux car tous les enregistrements ont le même état. La pagination de ces enregistrements ne sera ni efficace ni cohérente.

Le fait de fournir une valeur « Trier par » donne au cookie de pagination la capacité de classer les données par une valeur supplémentaire et de reconnaître le dernier enregistrement d’une page en fonction des valeurs fournies.

Exemple 1

Une requête est créée pour obtenir tous les enregistrements avec un état « Ouvert », inclure l’état de chaque enregistrement et afficher trois enregistrements par page. La requête est ensuite classée par statut. Le résultat de la requête s’affiche comme indiqué dans le tableau suivant :

Département Statut Page
Ouvert(e) Activé 1
Ouvert(e) Activé 1
Ouvert(e) Activé Fin de la page 1
Ouvert(e) Activé
Ouvert(e) Activé
Ouvert(e) Inactifs
Ouvert(e) Inactifs

Le cookie de pagination enregistrera des informations sur le dernier enregistrement de la page, mais lorsqu’il est temps d’accéder à la page deux dans cet exemple, il n’y a pas d’identificateur unique pour garantir que la page suivante remplie utilise les enregistrements non consultés ou inclut les deux premiers enregistrements qui ont été à la première page.

Pour résoudre ce problème, les requêtes doivent inclure des colonnes « Trier par » avec des valeurs uniques. Il est possible d’utiliser plusieurs valeurs « Trier par ». Voici une meilleure façon de classer les données pour cette requête :

Exemple 2

Une requête est créée pour obtenir tous les enregistrements d’un état « Ouvert », tout statut, inclure l’ID d’incident et afficher trois enregistrements par page. Elle trie par statut et par ID d’incident (un identificateur unique) qui triera par ordre croissant. Les résultats de la requête s’affiche comme suit :

Département Statut ID d’incident Page
Ouvert(e) Activé Incident-0010 1
Ouvert(e) Activé Incident-0021 1
Ouvert(e) Activé Incident-0032 Fin de la page 1
Ouvert(e) Activé Incident-0034
Ouvert(e) Activé Incident-0070
Ouvert(e) Inactifs Incident-0015
Ouvert(e) Inactifs Incident-0047

Les résultats de la requête sont d’abord classés par statut, puis classés par ID d’incident dans l’ordre croissant. Lorsque la page deux est générée, le résultat serait comme indiqué ci-dessous :

Département Statut ID d’incident Page
Ouvert(e) Activé Incident-0010
Ouvert(e) Activé Incident-0021
Ouvert(e) Activé Incident-0032 Fin de la page 1
Ouvert(e) Activé Incident-0034 2
Ouvert(e) Activé Incident-0070 2
Ouvert(e) Inactifs Incident-0015
Ouvert(e) Inactifs Incident-0047

Lors de la génération de la page deux de cet ensemble de requêtes, le cookie aura Incident-0032 stocké comme dernier enregistrement de la première page, de sorte que la page deux reprendra au prochain enregistrement de l’ensemble après cet enregistrement. Cela permettra des résultats plus cohérents.

Suggestions de classement

Vous trouverez ci-dessous quelques suggestions pour améliorer le classement des résultats de pagination, ainsi que certains domaines à éviter.

Meilleur classement

  • Incluez toujours une colonne qui a un identifiant unique (c.-à-d., colonnes d’ID de table, colonnes de numérotation automatique, ID d’utilisateur/de contact)

Bon classement

  • Incluez plusieurs champs qui entraîneront très probablement des combinaisons uniques :
    • Prénom + nom + adresse e-mail
    • Nom complet + adresse e-mail
    • Adresse e-mail + nom de l’entreprise

Mauvais classement

  • Classement qui n’inclue pas d’identificateurs uniques

  • Classements qui ont un ou plusieurs champs qui ne sont pas susceptibles de fournir un caractère unique, tels que :

    • Statut et état
    • Choix ou Oui/Non
    • Nommer les valeurs par elles-mêmes (c.-à-d. dernier seulement, premier seulement, nom de l’entreprise seulement)
    • Champs de texte comme les titres, les descriptions, le texte sur plusieurs lignes
    • Champs de nombres non uniques

Ordre et requêtes de table multiples

Parfois, des données qui couvrent plusieurs tables sont nécessaires et doivent être interrogées avec une table JOIN. Dans ces cas, l’ordre peut être inclus pour les deux tables de la requête. Assurez-vous d’utiliser au moins une colonne avec un ID unique par table pour garantir que la pagination donne les meilleurs résultats. Cependant, la requête sera rétrogradée à la pagination héritée, où aucun cookie de pagination ne sera renvoyé, dans ces cas en raison des limitations de la structure de relation N:1 qui pourraient entraîner des données manquantes.

Voir aussi

Page de grands ensembles de résultats avec FetchXML

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).