Modèles de données de requête optimisés

Le modèle de requête de données le plus simple et le plus rapide est :

1. Une seule table ou vue
2. Préfiltré sur le serveur selon vos besoins
3. Les colonnes sont indexées correctement pour les requêtes attendues

Lorsque vous concevez votre application, vous devez réfléchir à la façon d’interroger rapidement les données. La meilleure façon d’interroger des données consiste à utiliser une table ou une vue unique qui contient toutes les informations dont vous avez besoin et à la filtrer sur le serveur avant de l’afficher dans votre application. Vous devez également vous assurer que les colonnes que vous utilisez pour filtrer ou trier les données sont indexées correctement. Cela rend votre application plus rapide et plus fluide.

Par exemple, supposons que vous disposez d’une galerie qui affiche une liste de clients et de leurs vendeurs. Si vous stockez les informations du client et des vendeurs dans des tables distinctes, vous devez utiliser des recherches pour obtenir le nom de l’vendeur pour chaque client. Cela ralentit votre application, car elle doit exécuter de nombreuses requêtes dans l’autre table. Une meilleure façon est de créer une vue qui combine les informations des clients et des vendeurs dans une table, et d’utiliser cette vue comme source de données pour votre galerie. Votre application doit ensuite exécuter une seule requête pour obtenir toutes les données dont elle a besoin.

Il existe un compromis entre la vitesse des requêtes et la normalisation des données. La normalisation des données signifie que vous stockez les données une seule fois et évitez la duplication. Cela permet de maintenir la cohérence et la précision des données. Toutefois, vous devez parfois dupliquer certaines données pour rendre les requêtes plus rapides et plus faciles. Vous devez équilibrer ces deux objectifs dans la conception de votre application et la structure des tables. Sinon, votre application sera lente et déboguée, car elle doit effectuer de nombreuses tâches pour filtrer et joindre les données à partir de différentes tables.

Utiliser des vues côté serveur

Les vues sont probablement l’outil le plus courant pour équilibrer ces objectifs. Ils présentent une structure de table unique pour les requêtes, préfiltres les données selon vos besoins dans la requête, et permettent les consultations et les jointures avec d'autres tables. Étant donné que les filtres, les recherches et les jointures pour la vue sont calculées sur le serveur, la charge utile et le calcul côté client sont réduits.

Éviter un trop grand nombre de recherches sur une galerie

Une galerie peut afficher de nombreux enregistrements à partir d’une source de données. Mais parfois, vous devez afficher des informations supplémentaires provenant d’une autre source de données liée à l’origine. Par exemple, vous disposez d’une galerie qui affiche une liste de clients et vous souhaitez afficher le nom de l’vendeur affecté à chaque client. Le nom de l’vendeur est stocké dans une source de données différente de celle du client. Pour afficher le nom de l’vendeur, vous devez utiliser une fonction de recherche qui recherche l’enregistrement correspondant dans l’autre source de données. Cela développe la table d’origine avec les valeurs de recherche.

Toutefois, l’expansion de la table peut être très lente si vous disposez de nombreux enregistrements et de nombreuses recherches. Pour chaque enregistrement de la galerie, l’application doit exécuter une requête distincte vers l’autre source de données et obtenir la valeur de recherche. Cela signifie que l’application peut avoir besoin d’exécuter de nombreuses requêtes pour chaque enregistrement, ce qui peut prendre beaucoup de temps et affecter les performances de l’application. Cet anti-modèle est parfois appelé « N carré, (n^2) » ou un problème « N+1 ».

Utiliser StartsWith ou Filter

Power Fx fournit plusieurs façons de rechercher des données. En général, utilisez une expression qui tire parti d’un index comme StartsWith ou Filter au lieu d’une expression qui lit la table entière comme In. L’opérateur In est correct pour les collections en mémoire ou si la table de source de données externe est très petite.

Envisager de dupliquer des données

Parfois, les données sont lentes à accéder dans une requête, car elles sont stockées dans un autre emplacement ou format. Pour accélérer la requête, vous pouvez copier les données lentes et les stocker localement dans une table rapide et facile à interroger. Toutefois, cela signifie que les données locales peuvent ne pas être la version la plus mise à jour des données d’origine. Ensuite, exécutez un autre processus pour mettre à jour régulièrement les données locales. Ce processus peut être un flux Power Automate, un plug-in, une procédure stockée ou toute autre méthode qui peut déplacer des données d’un emplacement à un autre.

La fréquence requise pour la mise à jour des données locales dépend des besoins de votre entreprise. À quel point les données doivent-elles être récentes pour votre application ? Par exemple, supposons que vous travaillez pour Contoso, une entreprise qui vend des vélos. La liste des vélos disponibles est stockée dans une base de données Products que vous pouvez accéder via une API dans un connecteur personnalisé. Toutefois, supposons que l’appel d’API est lent, et que vous décidez donc de copier les données du produit et de les stocker localement dans une table. Ensuite, vous créez une vue qui combine votre table avec d’autres données pertinentes pour votre application. Vous créez également un flux Power Automate qui s’exécute chaque jour et met à jour votre table avec les dernières données de produit de l’API. Votre application peut ensuite interroger les données locales plus rapidement, et les données ne sont qu’un jour d’ancienneté au maximum.

La duplication de données est un type commun de technique dans les applications de niveau entreprise pour garantir de bonnes performances. Vous pouvez utiliser des plug-ins Dataverse, des procédures stockées ou un déplacement de données pour dupliquer des données dans une table unique optimisée pour l’interrogation. La question clé est la suivante : comment ces données doivent-elles être à jour ? Si vous pouvez vous permettre un certain délai, vous pouvez utiliser cette technique pour accélérer votre application.

Suggestions

Pour atteindre cet objectif, tenez compte des questions et suggestions suivantes :

1. Quelle est l’importance pour un client de voir la valeur des données dans une galerie ou une grille de données ? Est-il acceptable de sélectionner d’abord un enregistrement, puis d’afficher les données dans un formulaire ?
2. Une vue peut-elle effectuer la préparation nécessaire pour afficher le bon format des données ?
3. Utilisez-vous un opérateur « IN » là où un « StartsWith » peut fonctionner ?
4. À quel point vos données doivent-elles être actuelles ? Existe-t-il une stratégie de duplication de données que vous pouvez utiliser pour que votre requête fonctionne sur une table unique par défaut ?