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

  • Article

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

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

Lorsque vous concevez votre application, vous devez réfléchir à la manière d’interroger rapidement les données. La meilleure façon d’interroger des données consiste à utiliser une seule table ou vue contenant 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 correctement indexées. Cela rend votre application plus rapide et plus fluide.

Par exemple, supposons que vous ayez une galerie qui affiche une liste de clients et de leurs vendeurs. Si vous stockez les informations sur le client et le vendeur dans des tables distinctes, vous devez utiliser des recherches pour obtenir le nom du vendeur pour chaque client. Cela ralentit votre application car elle doit exécuter de nombreuses requêtes sur l’autre table. Une meilleure façon consiste à créer une vue qui combine les informations sur le client et le vendeur dans un seul tableau, et à utiliser cette vue comme source de données pour votre galerie. Ensuite, votre application n’a besoin d’exécuter qu’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 garder les données cohérentes et exactes. Cependant, 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 lente car elle doit effectuer de nombreux travaux pour filtrer et joindre les données de différentes tables.

Utiliser des vues côté serveur

Les vues sont probablement l’outil le plus courant pour aider à équilibrer ces objectifs. Ils présentent une structure de table unique pour les requêtes, préfiltrent les données pour ce dont vous avez besoin dans la requête et permettent des recherches et des jointures à d’autres tables. Étant donné que les filtres, les recherches et les jointures pour la vue sont calculés sur le serveur, la charge utile et le calcul côté client sont minimisés.

Une galerie peut afficher de nombreux enregistrements d’un source de données. Mais parfois, vous devez afficher des informations supplémentaires provenant d’un autre source de données lié à celui d’origine. Par exemple, vous disposez d’une galerie qui affiche une liste de clients et vous souhaitez afficher le nom du vendeur affecté à chaque client. Le nom du vendeur est stocké dans un source de données différent de celui des informations du client. Pour afficher le nom du vendeur, vous devez utiliser une fonction de recherche qui trouve 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 sur l’autre source de données et obtenir la valeur de recherche. Cela signifie que l’application devra peut-être 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 connu sous le nom de problème « N au carré, (n^2) » ou « N+1 ».

Utiliser StartsWith ou Filtrer.

Power Fx propose plusieurs façons de rechercher des données. En général, utilisez une expression qui exploite un index comme StartsWith ou Filtrer au lieu de celui qui lit le tableau entier comme Dans. L’opérateur In convient aux collections en mémoire ou si la table externe source de données est très petite.

Envisagez la duplication des données

Parfois, l’accès aux données est lent dans une requête car elles sont stockées dans un emplacement ou un format différent. 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 ne constituent peut-être pas la version la plus à jour des données originales. Exécutez ensuite un autre processus pour mettre à jour périodiquement 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 permettant de déplacer des données d’un endroit à un autre.

La fréquence requise pour la mise à jour des données locales dépend des besoins de votre entreprise. Dans quelle mesure les données doivent-elles être récentes pour votre application ? Par exemple, supposons que vous travailliez pour Contoso, une entreprise qui vend des vélos. La liste des vélos disponibles est stockée dans une base de données Produits à laquelle vous pouvez accéder via une API dans un connecteur personnalisé. Mais disons que l’appel 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 est exécuté quotidiennement et met à jour votre table avec les dernières données produit de l’API. Votre application peut alors interroger les données locales plus rapidement, et les données ne datent que d’un jour au maximum.

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

Suggestions

Pour atteindre cet objectif, considérez les questions et suggestions suivantes :

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