Del via

Optimaliserte spørringsdatamønstre

  • Artikkel

Det enkleste og raskeste dataspørringsmønsteret er som følger:

  1. Én tabell eller visning
  2. Forhåndsfiltrert på serveren til det du trenger
  3. Kolonner indekseres riktig for de forventede spørringene

Når du utformer appen, må du tenke på hvordan du raskt kan spørre etter dataene. Den beste måten å foreta spørring etter data på er å bruke én tabell eller visning som har all informasjonen du trenger, og filtrere den på serveren før du viser den i appen. Du må også sørge for at kolonnene du bruker til å filtrere eller sortere dataene, er riktig indeksert. Dette gjør appen raskere og mer friksjonsløst.

La oss for eksempel si at du har et galleri som viser en liste over kunder og selgerne deres. Hvis du lagrer kunde- og selgerinformasjonen i separate tabeller, må du bruke oppslag for å hente navnet på selgeren for hver kunde. Dette gjør appen din tregere fordi den må kjøre mange spørringer mot den andre tabellen. Det er bedre å lage en visning som kombinerer informasjonen om kunden og selgeren i én tabell, og bruke denne visningen som datakilde for galleriet. Appen trenger dermed bare å kjøre én spørring for å hente alle dataene den trenger.

Det er et kompromiss mellom spørringshastighet og datanormalisering. Datanormalisering betyr at du bare lagrer dataene én gang, og unngår duplisering. Dette bidrar til å holde dataene konsekvente og nøyaktige. Du må imidlertid av og til duplisere enkelte data for å gjøre spørringene raskere og enklere. Du må balansere disse to målene i apputformingen og tabellstrukturen. Ellers kommer appen til å bli treg og ujevn fordi den må gjøre mye arbeid for å filtrere og slå sammen dataene fra ulike tabeller.

Bruk visninger på serversiden

Visninger er sannsynligvis det vanligste verktøyet som bidrar til å balansere disse målene. De viser én tabellstruktur for spørringer, forhåndsfiltrerer data for det du trenger i spørringen, og aktiverer oppslag og sammenkoblinger til andre tabeller. Siden filtrene, oppslagene og sammenføyningene for visningen beregnes på serveren, minimeres både nyttelasten og databehandlingen på klientsiden.

Et galleri kan vise mange oppføringer fra en datakilde. Du må imidlertid av og til vise tilleggsinformasjon fra en annen datakilde som er relatert til den opprinnelige. La oss si at du for eksempel har et galleri som viser en liste over kunder, og du ønsker å vise navnet på selgeren som er tilordnet til hver kunde. Navnet på selgeren lagres i en annen datakilde enn informasjonen om kunden. Hvis du vil vise navnet på selgeren, må du bruke en oppslagsfunksjon som finner den samsvarende oppføringen i den andre datakilden. Dette utvider den opprinnelige tabellen med oppslagsverdiene.

Det kan imidlertid gå svært tregt å utvide tabellen hvis du har mange oppføringer og mange oppslag. For hver oppføring i galleriet må appen kjøre en egen spørring mot den andre datakilden og hente oppslagsverdien. Dette betyr at appen kanskje må kjøre mange spørringer for hver oppføring, som kan ta lang tid og påvirke appytelsen. Dette antimønsteret kan kalles «N opphøyd i andre, (n^2)» eller et «N+1»-problem.

Bruk StartsWith eller Filter

Du kan søke etter data på flere måter med Power Fx. Bruk generelt sett et uttrykk som utnytter en indeks som StartsWith eller Filter i stedet for et som leser hele tabellen, for eksempel In. In-operatoren er grei å bruke til samlinger i minnet eller hvis tabellen for ekstern datakilde er svært liten.

Vurder å duplisere data

Data er av og til trege å få tilgang til data i en spørring fordi de er lagret i en annen plassering eller et annet format. Du kan gjøre spørringen raskere ved å kopiere de trege dataene og lagre dem lokalt i en tabell som er rask og enkel å spørre. Dette betyr imidlertid at de lokale dataene kanskje ikke er den mest oppdaterte versjonen av de opprinnelige dataene. Kjør deretter en annen prosess for å oppdatere de lokale dataene med jevne mellomrom. Denne prosessen kan være en Power Automate-flyt, et programtillegg, en lagret prosedyre eller enhver annen metode som kan flytte data fra en plassering til et annen.

Frekvenskravet for oppdatering av de lokale dataene avhenger av bedriftens behov. Hvor ferske må dataene være for appen? La oss for eksempel si at du jobber for Contoso, et firma som selger sykler. Listen over tilgjengelige sykler er lagret i en produktdatabase du har tilgang til via en API i en egendefinert kobling. La oss imidlertid si at API-oppkallet er tregt, så derfor bestemmer du deg for å kopiere produktdataene og lagre dem lokalt i en tabell. Du oppretter deretter en visning som kombinerer tabellen med andre relevante data for appen. Du oppretter også en Power Automate-flyt som kjører hver dag og oppdaterer tabellen med de nyeste produktdataene fra API-en. Appen kan deretter foreta spørringer mot de lokale dataene raskere, og dataene er bare én dag gamle på det meste.

Duplisering av data er en vanlig type teknikk i programmer i bedriftsklassen for å sikre god ytelse. Du kan bruke Dataverse-programtillegg, lagrede prosedyrer eller dataflytting til å duplisere data til én tabell som er optimalisert for spørring. Nøkkelspørsmålet er hvor oppdatert disse dataene må være? Hvis du har råd til litt forsinkelse, kan du bruke denne teknikken til å øke hastigheten på appen.

Forslag

Du kan oppnå dette målet ved å ta hensyn til følgende spørsmål og forslag:

  1. Hvor viktig er det for en kunde å se dataverdien i et galleri eller datarutenett? Hadde det vært akseptabelt å først velge en oppføring og deretter vise dataene i et skjema?
  2. Kan en visning gjøre forhåndsarbeidet som trengs for å vise data i riktig format?
  3. Bruker du en «IN»-operator der en «StartsWith» hadde fungert?
  4. Hvor ferske må dataene dine være? Finnes det en datadupliseringsstrategi du kan bruke til å få spørringen til å fungere over én tabell som standard?