Optimerede forespørgselsdatamønstre
Det enkleste og hurtigste dataforespørgselsmønster er:
- En enkelt tabel eller visning
- Forfiltreret på serveren til det du har brug for
- Kolonner er indekseret korrekt for de forventede forespørgsler
Når du designer din app, skal du tænke over, hvordan du hurtigt kan forespørge dataene. Den bedste måde at forespørge data på er at bruge en enkelt tabel eller visning, der har alle de oplysninger, du har brug for, og filtrere dem på serveren, før du viser dem i din app. Du skal også sørge for, at de kolonner, du bruger til at filtrere eller sortere dataene, er indekseret korrekt. Dette gør din app hurtigere og mere smidig.
Antag for eksempel, at du har et galleri, der viser en liste over kunder og deres sælgere. Hvis du gemmer kunde- og sælgeroplysningerne i separate tabeller, skal du bruge opslag for at få sælgernavnet for hver kunde. Dette gør din app langsommere, fordi den skal køre mange forespørgsler til den anden tabel. En bedre måde er at oprette en visning, der kombinerer kunde- og sælgeroplysningerne i én tabel, og bruge denne visning som datakilde for dit galleri. Så behøver din app kun at køre én forespørgsel for at få alle de data, den har brug for.
Der er en afvejning mellem forespørgselshastighed og datanormalisering. Datanormalisering betyder, at du kun gemmer dataene én gang og undgår duplikering. Dette hjælper med at holde dataene konsistente og nøjagtige. Nogle gange er du dog nødt til at duplikere nogle data for at gøre forespørgslerne hurtigere og nemmere. Du skal balancere disse to mål i dit appdesign og tabelstruktur. Ellers vil din app være langsom og haltende, fordi den skal udføre talrige arbejde for at filtrere og samle data fra forskellige tabeller.
Brug visninger på serversiden
Visninger er nok det mest almindelige værktøj til at hjælpe med at balancere disse mål. De præsenterer en enkelt tabelstruktur for forespørgsler, forfiltrerer data til det, du har brug for i forespørgslen, og aktiverer opslag og sammenkædninger til andre tabeller. Fordi filtrene, opslagene og joinforbindelserne for visningen beregnes på serveren, minimeres både nyttelasten og klientsiden.
Undgå for mange opslag på et galleri
Et galleri kan vise mange poster fra en datakilde. Men nogle gange skal du vise yderligere information fra en anden datakilde, der er relateret til den originale. For eksempel har du et galleri, der viser en liste over kunder, og du vil vise navnet på den sælger, der er tildelt hver kunde. Sælgerens navn er gemt i en anden datakilde end kundens oplysninger. For at vise sælgerens navn skal du bruge en opslagsfunktion, der finder den matchende post i den anden datakilde. Dette udvider den oprindelige tabel med opslagsværdierne.
Udvidelse af tabellen kan dog være meget langsom, hvis du har mange poster og mange opslag. For hver post i galleriet skal appen køre en separat forespørgsel til den anden datakilde og få opslagsværdien. Det betyder, at appen muligvis skal køre mange forespørgsler for hver post, hvilket kan tage lang tid og påvirke appens ydeevne. Dette anti-mønster er nogle gange kendt som "N squared, (n^2)" eller et "N+1" problem.
Brug StartsWith eller Filter
Power Fx giver flere måder at søge data på. Brug generelt et udtryk, der udnytter et indeks som StartsWith eller Filter i stedet for en, der læser hele tabellen som In. In-operatoren er fin til samlinger i hukommelsen, eller hvis den eksterne datakilde-tabel er meget lille.
Overvej duplikering af data
Nogle gange er data langsomme at få adgang til i en forespørgsel, fordi de er gemt på en anden placering eller et andet format. For at gøre forespørgslen hurtigere kan du kopiere de langsomme data og gemme dem lokalt i en tabel, der er hurtig og nem at forespørge på. Det betyder dog, at de lokale data muligvis ikke er den mest opdaterede version af de originale data. Kør derefter en anden proces for at opdatere de lokale data med jævne mellemrum. Denne proces kan være et Power Automate-flow, et plugin, en lagret procedure eller enhver anden metode, der kan flytte data fra et sted til et andet.
Hyppighedskravet for opdatering af de lokale data afhænger af dine forretningsbehov. Hvor frisk skal dataene være for din app? Antag for eksempel, at du arbejder for Contoso, et firma, der sælger cykler. Listen over tilgængelige cykler er gemt i en produktdatabase, som du kan få adgang til via en API i en brugerdefineret forbindelse. Men lad os sige, at API-kaldet er langsomt, så du beslutter dig for at kopiere produktdataene og gemme dem lokalt i en tabel. Derefter opretter du en visning, der kombinerer din tabel med andre relevante data for din app. Du opretter også et Power Automate-flow, der kører hver dag og opdaterer din tabel med de seneste produktdata fra API'en. Så kan din app forespørge de lokale data hurtigere, og dataene er højst kun én dag gamle.
Duplikering af data er en almindelig type teknik i enterprise-grade applikationer for at sikre god ydeevne. Du kan bruge Dataverse-plugins, lagrede procedurer eller dataflytning for at duplikere data til en enkelt tabel, der er optimeret til forespørgsler. Det centrale spørgsmål er: hvor opdaterede skal disse data være? Hvis du har råd til en vis forsinkelse, kan du bruge denne teknik til at fremskynde din app.
Forslag
For at nå målet skal du overveje følgende spørgsmål og forslag:
- Hvor vigtigt er det for en kunde at se dataværdien i et galleri eller et datagitter? Ville det være acceptabelt først at vælge en post og derefter vise dataene i en formular?
- Kan en visning udføre det forarbejde, der er nødvendigt for at se data i det rigtige format?
- Bruger du en "IN"-operator, hvor en "StartsWith" vil fungere?
- Hvor aktuelle skal dine data være? Er der en dataduplikeringsstrategi, du kan bruge til at få din forespørgsel til at fungere over en enkelt tabel som standard?