Optimeeritud päringuandmete mustrid

Lihtsaim ja kiireim andmepäringu muster on järgmine.

1. Üks tabel või vaade
2. Eelfiltreeritud serveris sellele, mida vajate
3. Veerud on oodatud päringute jaoks õigesti indekseeritud

Rakenduse kujundamisel peate mõtlema, kuidas andmeid kiiresti pärida. Parim viis andmete päringute tegemiseks on kasutada ühte tabelit või vaadet, mis sisaldab kogu vajalikku teavet, ja filtreerida see serveris enne rakenduses kuvamist. Samuti peate veenduma, et andmete filtreerimiseks või sortimiseks kasutatavad veerud on õigesti indekseeritud. See muudab teie rakenduse kiiremaks ja sujuvamaks.

Oletame näiteks, et teil on galerii, mis näitab klientide ja nende müügiesindajate loendit. Kui talletate kliendi ja müüja teabe eraldi tabelites, peate iga kliendi müügiesindaja nime saamiseks kasutama otsinguid. See aeglustab teie rakendust, kuna see peab käivitama palju päringuid teisele tabelile. Parem viis on luua vaade, mis ühendab kliendi ja müügiesindaja teabe ühte tabelisse, ja kasutada seda vaadet oma galerii andmeallikana. Seejärel peab teie rakendus kõigi vajalike andmete saamiseks käivitama ainult ühe päringu.

Päringu kiiruse ja andmete normaliseerimise vahel on kompromiss. Andmete normaliseerimine tähendab, et salvestate andmeid ainult üks kord ja väldite dubleerimist. See aitab hoida andmeid järjepidevana ja täpsena. Kuid mõnikord peate päringute kiiremaks ja lihtsamaks muutmiseks mõned andmed dubleerima. Peate need kaks eesmärki oma rakenduse kujunduses ja tabeli struktuuris tasakaalustama. Vastasel juhul on teie rakendus aeglane ja viivitusega, kuna see peab tegema palju tööd, et filtreerida ja ühendada eri tabelite andmeid.

Serveripoolsete vaadete kasutamine

Vaated on ilmselt kõige levinum vahend nende eesmärkide tasakaalustamiseks. Need esitavad päringute jaoks ühtse tabelistruktuuri, eelfiltreerivad päringus vajalikke andmeid ning võimaldavad otsinguid ja ühendusi teiste tabelitega. Kuna vaate filtrid, otsingud ja ühendused arvutatakse serveris, on nii kasulik koormus kui ka kliendipoolne arvutus minimeeritud.

Liiga paljude otsingute vältimine galeriis

Galeriis saab kuvada palju andmeallika kirjeid. Kuid mõnikord peate kuvama lisateavet mõnest muust andmeallikast, mis on seotud algse andmeallikaga. Näiteks on teil galerii, kus kuvatakse klientide loend ja soovite kuvada igale kliendile määratud müügiesindaja nime. Müüja nimi talletatakse kliendi teabest erinevas andmeallikas. Müügiesindaja nime kuvamiseks peate kasutama otsingufunktsiooni, mis leiab vastava kirje teisest andmeallikast. See laiendab algset tabelit otsinguväärtustega.

Tabeli laiendamine võib aga olla väga aeglane, kui teil on palju kirjeid ja palju otsinguid. Iga galerii kirje puhul peab rakendus käivitama eraldi päringu teisele andmeallikale ja hankima otsinguväärtuse. See tähendab, et rakendusel võib olla vaja käivitada iga kirje jaoks palju päringuid, mis võib võtta kaua aega ja mõjutada rakenduse jõudlust. Seda antimustrit nimetatakse mõnikord "N ruuduks, (n^2)" või "N+1" probleemiks.

StartsWith või filtri kasutamine

Power Fx pakub andmete otsimiseks mitmeid võimalusi. Üldiselt kasutage avaldist, mis kasutab indeksit (nt StartsWith või Filter ), selle asemel, et lugeda kogu tabelit ( nt In). Tehtemärk In sobib mälusiseste kogumite jaoks või kui välise andmeallika tabel on väga väike.

Kaaluge andmete dubleerimist

Mõnikord on andmetele päringus juurdepääs aeglane, kuna need on talletatud muus asukohas või vormingus. Päringu kiiremaks muutmiseks saate aeglased andmed kopeerida ja talletada need kohapeal tabelis, kus on kiire ja lihtne päringuid teha. See aga tähendab, et kohalikud andmed ei pruugi olla algandmete kõige värskemad versioonid. Seejärel käivitage kohalike andmete perioodiliseks värskendamiseks mõni muu protsess. See protsess võib olla Power Automate'i voog, lisandmoodul, salvestatud protseduur või mõni muu meetod, mis saab andmeid ühest kohast teise teisaldada.

Kohalike andmete värskendamise sagedusnõue sõltub teie ettevõtte vajadustest. Kui värsked peavad teie rakenduse andmed olema? Oletame näiteks, et töötate jalgrattaid müüvas ettevõttes Contoso. Saadaolevate jalgrataste loend on salvestatud toodete andmebaasi, millele pääsete juurde kohandatud konnektori API kaudu. Kuid oletame, et API kutse on aeglane ja seega otsustate kopeerida tooteandmed ja salvestada need lokaalselt tabelisse. Seejärel loote vaate, mis ühendab teie tabeli muude teie rakenduse jaoks asjakohaste andmetega. Samuti loote Power Automate'i voo, mis töötab iga päev ja värskendab teie tabelit API uusimate tooteandmetega. Siis saab teie rakendus kohalikke andmeid kiiremini pärida ja andmed on maksimaalselt ühe päeva vanad.

Andmete dubleerimine on ettevõtte tasemel rakendustes levinud tehnika hea jõudluse tagamiseks. Saate kasutada Dataverse'i lisandmooduleid, salvestatud protseduure või andmete teisaldamist, et dubleerida andmed ühte tabelisse, mis on päringute jaoks optimeeritud. Põhiküsimus on: kui ajakohased peavad need andmed olema? Kui saate endale lubada viivitust, saate seda tehnikat kasutada oma rakenduse kiirendamiseks.

Ettepanekud

Selle eesmärgi saavutamiseks kaaluge järgmisi küsimusi ja soovitusi:

1. Kui oluline on kliendi jaoks näha andmeväärtust galeriis või andmeruudustikus? Kas oleks vastuvõetav valida esmalt kirje ja seejärel kuvada andmed vormil?
2. Kas vaade saab teha eeltööd, mis on vajalik andmete õiges vormingus nägemiseks?
3. Kas kasutate "IN" operaatorit, kus "StartsWith" töötab?
4. Kui ajakohased peavad teie andmed olema? Kas on olemas andmete dubleerimise strateegia, mille abil saate oma päringu vaikimisi ühes tabelis töötada?