Optimalizált lekérdezési adatminták

A legegyszerűbb és leggyorsabb adat lekérdezési minta a következő:

1. Egyetlen tábla vagy nézet
2. Igényei szerint előre szűrve a kiszolgálón
3. Az oszlopok indexelése megfelelően történik a várt lekérdezésekhez

Az alkalmazás tervezésekor végig kell gondolnia, hogyan kérdezheti le gyorsan az adatokat. Az adatok lekérdezésének legjobb módja, ha egyetlen táblát vagy nézetet használ, amely minden szükséges információt tartalmaz, és szűri azokat a kiszolgálón, mielőtt megjelenítené az alkalmazásban. Meg kell bizonyosodnia arról is, hogy az adatok szűréséhez vagy rendezéséhez használt oszlopok megfelelően vannak indexelve. Így az alkalmazás gyorsabban és gördülékenyebben halad.

Tegyük fel például, hogy van egy katalógusa, amely megjeleníti az ügyfelek és az értékesítők listáját. Ha az ügyfél és az üzletkötő adatait külön táblákban tárolja, a keresések használatával lekérheti az egyes ügyfelek értékesítői nevét. Ez lelassítja az alkalmazást, mert sok lekérdezést kell futtatnia a másik táblában. Jobb módszer egy olyan nézet létrehozása, amely egyetlen táblában egyesíti az ügyfél és az üzletkötő adatait, és ezt a nézetet használja a katalógus adatforrásaként. Ezután az alkalmazásnak csak egy lekérdezést kell futtatnia az összes szükséges adat lekéréséhez.

A lekérdezési sebesség és az adatok normalizálása között kompromisszum áll fenn. Az adatok normalizálása azt jelenti, hogy csak egyszer tárolja az adatokat, és elkerüli a duplikációt. Ez segít az adatok konzisztens és pontos megőrzésében. Néha azonban duplikálnia kell néhány adatot, hogy a lekérdezések gyorsabban és egyszerűbben legyenek. Ezt a két célt ki kell egyensúlyoznia az alkalmazástervezésben és a táblázatstruktúrában. Ellenkező esetben az alkalmazás lassú és lassú lesz, mert számos munkát kell elvégeznie a különböző táblákból származó adatok szűréséhez és összekapcsolásához.

Kiszolgálóoldali nézetek használata

A nézetek valószínűleg a leggyakoribb eszközök ezeknek a céloknak a kiegyensúlyozására. Egyetlen táblastruktúrát mutatnak be a lekérdezésekhez, előszűrik a lekérdezésben szükséges adatokat, és engedélyezik a kereséseket és a más táblákhoz való illesztéseket. A nézet szűrői, keresései és illesztései a kiszolgálón vannak feldolgozva, így az adatforgalom és az ügyféloldali számítás is minimálisra csökken.

Túl sok keresés elkerülése egy képtárban

A katalógus számos rekordot jeleníthet meg egy adatforrásból. Néha azonban meg kell jelenítenie az eredeti adatforráshoz kapcsolódó további információkat egy másik adatforrásból. Van például egy katalógusa, amely megjeleníti az ügyfelek listáját, és meg szeretné jeleníteni az egyes ügyfelekhez rendelt értékesítő nevét. Az értékesítő neve az ügyfél adataitól eltérő adatforrásban van tárolva. Az értékesítő nevének megjelenítéséhez egy keresési függvényt kell használnia, amely megkeresi az egyező rekordot a másik adatforrásban. Ezzel kibontja az eredeti táblát a keresési értékekkel.

A tábla kibővítése azonban nagyon lassú lehet, ha sok rekord és sok lekérdezés van. A katalógus minden rekordjához az alkalmazásnak külön lekérdezést kell futtatnia a másik adatforráshoz, és le kell szereznie a keresési értéket. Ez azt jelenti, hogy az alkalmazásnak több lekérdezést kell futtatnia minden rekordhoz, ami hosszú időt vehet igénybe, és hatással lehet az alkalmazás teljesítményére. Ezt az antimintát néha "N négyzetesnek, (n^2)" vagy "N+1" problémának is nevezik.

A StartsWith vagy a Filter használata

A Power Fx számos módot kínál az adatok keresésére. Általában olyan kifejezést használjon, amely egy olyan indexet használ, mint a StartsWith vagy a Filter , ahelyett, hogy a teljes táblázatot beolvassa, mint például az In. Az In operátor a memóriabeli gyűjtemények esetében megfelelő, vagy ha a külső adatforrás táblázata nagyon kicsi.

Fontolja meg az adatok duplikálását

Előfordulhat, hogy az adatok lassan érhetők el egy lekérdezésben, mert más helyen vagy formátumban vannak tárolva. A lekérdezés gyorsabbá tétele érdekében másolhatja a lassú adatokat, és helyben tárolhatja őket egy gyors és könnyen lekérdezhető táblában. Ez azonban azt jelenti, hogy előfordulhat, hogy a helyi adatok nem az eredeti adatok legfrissebb verziója. Ezután futtasson egy másik folyamatot a helyi adatok rendszeres frissítéséhez. Ez a folyamat lehet Power Automate-folyamat, beépülő modul, tárolt eljárás vagy bármely más módszer, amely adatokat helyezhet át egyik helyről a másikra.

A helyi adatok frissítésének gyakorisági követelménye az üzleti igényektől függ. Mennyire frissek az adatok az alkalmazáshoz? Tegyük fel például, hogy a Contoso vállalatnál dolgozik, amely kerékpárokat értékesít. Az elérhető kerékpárok listája egy Products adatbázisban található, amelyet egy API-val érhet el egy egyéni összekötőben. Tegyük fel azonban, hogy az API-hívás lassú, ezért úgy dönt, hogy kimásolja a termékadatokat, és helyileg tárolja őket egy táblában. Ezután létrehoz egy nézetet, amely egyesíti a táblázatot az alkalmazás egyéb releváns adataival. Olyan Power Automate-folyamatot is létrehozhat, amely naponta fut, és frissíti a táblát az API legújabb termékadataival. Ezután az alkalmazás gyorsabban lekérdezheti a helyi adatokat, és az adatok legfeljebb egy naposak.

Az adatok duplikálása a nagyvállalati szintű alkalmazások gyakori technikája a jó teljesítmény biztosítása érdekében. A Dataverse beépülő modulokkal, a tárolt eljárásokkal vagy az adatáthelyezéssel adatokat duplikálhat egyetlen, lekérdezésre optimalizált táblába. A fő kérdés a következő: mennyire kell naprakésznek lenniük az adatoknak? Ha megengedhet magának némi késést, ezzel a technikával felgyorsíthatja az alkalmazást.

Suggestions

A cél eléréséhez vegye figyelembe a következő kérdéseket és javaslatokat:

1. Mennyire fontos, hogy egy ügyfél láthassa adatai értékét egy gyűjteményben vagy rácsban? Elfogadható lenne először kijelölni egy rekordot, majd megjeleníteni az adatokat egy űrlapon?
2. Meg tudja-e adni a nézet az adatok megfelelő formátumban való megtekintéséhez szükséges előmunkát?
3. Az „IN” operátort használja, ott ahol a „StartsWith” is működhetne?
4. Milyen naprakésznek kell lennie az adatoknak? Van olyan adatkettőződési stratégia, amellyel a lekérdezést alapértelmezés szerint egyetlen táblán tudja működtetni?