Comportamientos y orden de paginación
Al consultar datos usando FetchXML, los resultados de la consulta de paginación pueden facilitar la visualización de grandes volúmenes de información. Cuando se utiliza la paginación, es importante incluir también los parámetros de ordenación. Sin un orden adecuado, las solicitudes de paginación para los "siguientes 50" registros pueden resultar en la recuperación de los mismos registros durante varias páginas, lo que dificulta las revisiones y ediciones. Una orden adecuado de las páginas requiere la inclusión de valores únicos para ayudar a identificar los registros que se incluyen en una página.
Paginación heredada
La paginación heredada dentro de Microsoft Dataverse carga todos los resultados de la consulta hasta la página actual en la memoria del servidor, selecciona la cantidad de registros que se necesitan para la página e ignora el resto. Esto tiene ventajas, como la paginación rápida hacia atrás y hacia adelante a través de los datos, o poder saltar a una página específica, pero también tiene restricciones, como un límite de 50 000 filas, problemas de rendimiento de las consultas grandes y complejas, y una ordenación arbitraria de los distintos resultados de consulta.
Ordenación con una cookie de paginación
Al realizar la paginación con ordenación, se almacena una caché con los resultados de la página anterior en una cookie de paginación. Esto se utiliza para calcular lo que debería mostrar la siguiente página de datos.
Si un usuario no especifica ningún parámetro "order by", el sistema insertará automáticamente "order by "<<entity name>>".<<entityId>> asc" para proporcionar una ordenación básica. En función de los datos que se estén consultando, esto puede devolver resultados inadecuados e inesperados, ya que un solo usuario del sistema puede estar asociado con múltiples registros dentro de cualquier consulta.
Si se utilizan consultas FetchXML distintas, el sistema no agregará ningún pedido adicional debido a posibles impactos en los datos devueltos. En estos casos, los usuarios deberán agregar al menos un valor de ordenación único para una experiencia de paginación más coherente.
Nota
La paginación usando FetchXML para Dataverse es dinámica. La página en la que aparece un registro se determina en el momento en que se representa cada página. Si se muestran 1000 registros, 50 por página, los primeros 50 registros se muestran como la página uno. Cuando se solicita la página dos, el sistema determina cuáles deben ser los siguientes 50 registros en el momento de la solicitud. Por ello, no es posible utilizar la nueva funcionalidad de paginación para paginar hacia atrás. El comportamiento heredado se utiliza para la paginación hacia atrás, que tendrá un rendimiento reducido y, debido a limitaciones heredadas, no será posible retroceder más allá de la página 500. 
¿Por qué es importante la ordenación?
Si se ejecuta una consulta para recuperar todos los registros con el estado "Abierto", se podrían devolver 1000 resultados. Al pasar de la página uno a la página dos, no hay forma de que el sistema sepa qué ordenaciones mostrar en la página dos, ya que todos los registros tienen el mismo estado. La paginación de estos registros no será eficaz ni coherente.
Proporcionar un valor "order by" (ordenar por) le da a la cookie de paginación la capacidad de ordenar los datos por un valor adicional y reconocer el último registro en una página según los valores proporcionados.
Ejemplo 1
Se crea una consulta para obtener todos los registros con el estado 'Abierto', se incluye el estado de cada registro y se muestran tres registros por página. A continuación, la consulta se ordena por estado. El resultado de la consulta se paginará como se muestra en la siguiente tabla:
| Est. | Estado | Página |
|---|---|---|
| Abierto | Activas | 1 |
| Abierto | Activas | 1 |
| Abierto | Activas | Final de la página 1 |
| Abierto | Activas | |
| Abierto | Activas | |
| Abierto | Inactivas | |
| Abierto | Inactivas |
La cookie de paginación guardará información sobre el último registro de la página, pero cuando llegue el momento de obtener la página dos en este ejemplo, no hay un identificador único para garantizar que la siguiente página rellenada utilice los registros no visualizados o incluya los dos primeros registros que estaban en la página uno.
Para solucionar este problema, las consultas deben incluir columnas "order by" que tengan valores únicos. Es posible utilizar varios valores "order by". A continuación, se muestra una manera mejor de ordenar los datos para esta consulta:
Ejemplo 2
Se crea una consulta para obtener todos los registros con el estado 'Abierto', con cualquier estado, se incluyen los id. de caso se muestran tres registros por página. Ordena por estado y por id. de caso (un identificador único), que se ordenará en orden ascendente. El resultado de la consulta paginará los resultados como se muestra a continuación:
| Est. | Estado | Id. de caso | Página |
|---|---|---|---|
| Abierto | Activas | Caso-0010 | 1 |
| Abierto | Activas | Caso-0021 | 1 |
| Abierto | Activas | Caso-0032 | Final de la página 1 |
| Abierto | Activas | Caso-0034 | |
| Abierto | Activas | Caso-0070 | |
| Abierto | Inactivas | Caso-0015 | |
| Abierto | Inactivas | Caso-0047 |
Los resultados de la consulta se ordenan primero por estado y luego por id. de caso en orden ascendente. Cuando se genera la página dos, el resultado sería el que se muestra a continuación:
| Est. | Estado | Id. de caso | Página |
|---|---|---|---|
| Abierto | Activas | Caso-0010 | |
| Abierto | Activas | Caso-0021 | |
| Abierto | Activas | Caso-0032 | Final de la página 1 |
| Abierto | Activas | Caso-0034 | 2 |
| Abierto | Activas | Caso-0070 | 2 |
| Abierto | Inactivas | Caso-0015 | |
| Abierto | Inactivas | Caso-0047 |
Al generar la página dos de este conjunto de consultas, la cookie tendrá el Caso-0032 almacenado como el último registro en la primera página, por lo que la página dos tomará el siguiente registro en el conjunto después de ese registro. Esto permite obtener resultados más coherentes.
Sugerencias de ordenación
A continuación se enumeran algunas sugerencias para mejorar el orden de los resultados de paginación, junto con algunas áreas que se deben evitar.
Mejor ordenación
- Incluya siempre una columna que tenga un identificador único (es decir, columnas de id. de tabla, columnas de numeración automática, id. de usuario/contacto)
Ordenación buena
- Incluya varios campos que probablemente generen combinaciones únicas:
- Nombre + apellido + dirección de correo electrónico
- Nombre completo + dirección de correo electrónico
- Dirección de correo electrónico + nombre de la empresa
Ordenación deficiente
Órdenes que no incluyen identificadores únicos
Órdenes que tienen campos únicos o múltiples que es poco probable que proporcionen unicidad, como:
- Estatus y estado
- Elecciones o Sí/No
- Valores de nombre por sí mismos (es decir, solo el apellido, solo el nombre, solo el nombre de la empresa)
- Campos de texto como títulos, descripciones, texto de varias líneas
- Campos numéricos no únicos
Pedidos y consultas de varias tablas
A veces, se necesitan datos que abarcan varias tablas y deben consultarse con una tabla JOIN. En estos casos, la ordenación se puede incluir para ambas tablas en la consulta. Asegúrese de utilizar al menos una columna con un id. único por tabla para garantizar que la paginación proporcione los mejores resultados. Sin embargo, la consulta pasará a la paginación heredada, que no devolverá ninguna cookie de paginación. En estos casos se debe a las limitaciones de la estructura de relación N:1, que puede provocar que falten datos.
Consulte también
Paginar conjuntos de resultados grandes con FetchXML
Nota
¿Puede indicarnos sus preferencias de idioma de documentación? Realice una breve encuesta. (tenga en cuenta que esta encuesta está en inglés)
La encuesta durará unos siete minutos. No se recopilan datos personales (declaración de privacidad).