Optimalizált lekérdezési adatminták

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

1. Egyetlen tábla vagy nézet
2. Előszűrve a kiszolgálón a szükséges tartalomra
3. Az oszlopok indexelése megfelelően történik a várt lekérdezésekhez

Az alkalmazás tervezésekor át kell gondolnia, hogyan lehet gyorsan lekérdezni az adatokat. Az adatok lekérdezésének legjobb módja, ha egyetlen táblát vagy nézetet használ, amely tartalmazza az összes szükséges információt, és szűri azokat a kiszolgálón, mielőtt megjelenítené őket az alkalmazásban. Győződjön meg arról is, hogy az adatok szűréséhez vagy rendezéséhez használt oszlopok indexelése megfelelő. Ez gyorsabbá és zökkenőmentesebbé teszi az alkalmazást.

Tegyük fel például, hogy van egy katalógusa, amely a vevők és értékesítőik listáját jeleníti meg. Ha a vevő és az értékesítő adatait külön táblákban tárolja, kereséseket kell használnia az egyes vevők üzletkötőjének nevének lekéréséhez. Ez lelassítja az alkalmazást, mert sok lekérdezést kell futtatnia a másik táblához. Jobb módszer, ha létrehoz egy nézetet, amely egyetlen táblában egyesíti a vevő és az értékesítő adatait, és ezt a nézetet használja a katalógus adatforrás. 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 adatnormalizálás között kompromisszum van. Az adatnormalizálás azt jelenti, hogy csak egyszer tárolja az adatokat, és elkerüli a duplikációt. Ez segít megőrizni az adatok konzisztenciáját és pontosságát. Néha azonban duplikálnia kell néhány adatot, hogy a lekérdezések gyorsabbak és egyszerűbbek legyenek. Ezt a két célt egyensúlyba kell hoznia az alkalmazás kialakításában és a táblázat szerkezetében. Ellenkező esetben az alkalmazás lassú és akadozó 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 e célok kiegyensúlyozására. Egyetlen táblastruktúrát jelenítenek meg a lekérdezésekhez, előszűrik az adatokat a lekérdezésben szükséges adatokhoz, és lehetővé teszik a kereséseket és a más táblákhoz való illesztéseket. Mivel a nézet szűrői, keresései és illesztései a kiszolgálón vannak kiszámítva, mind a hasznos adat, mind az ügyféloldali számítás minimalizálva van.

Kerülje a túl sok keresést egy katalógusban

A katalógusok egy adatforrás számos rekordját megjeleníthetik. De néha további információkat kell megjelenítenie egy másik adatforrás, amely az eredetihez kapcsolódik. Tegyük fel például, hogy van egy katalógusa, amely a vevők listáját jeleníti meg, és meg szeretné jeleníteni az egyes vevőkhöz rendelt értékesítő nevét. Az értékesítő neve más adatforrás tárolódik, mint az ügyfél adatai. Az üzletkötő nevének megjelenítéséhez olyan keresőfüggvényt kell használnia, amely megkeresi az egyező rekordot a másik adatforrás. Ezzel kibővíti az eredeti táblát a keresési értékekkel.

A tábla kibontása azonban nagyon lassú lehet, ha sok rekorddal és sok kereséssel rendelkezik. A katalógus minden rekordjához az alkalmazásnak külön lekérdezést kell futtatnia a másik adatforrás, és le kell kérnie a keresési értéket. Ez azt jelenti, hogy előfordulhat, hogy az alkalmazásnak sok 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 a kizárási mintát néha "N négyzetes, (n^2)" vagy "N+1" problémának is nevezik.

A StartsWith vagy a Filter használata

Power Fx Számos lehetőséget kínál az adatok keresésére. Általában olyan kifejezést használjon, amely olyan indexet használ, mint a StartsWith vagy a Filter, ahelyett, hogy a teljes táblázatot beolvasná (például In). Az In operátor megfelelő a memóriában tárolt gyűjteményekhez, vagy ha a külső adatforrás tábla nagyon kicsi.

Fontolja meg az adatok duplikálását

Néha az adatok elérése lassú 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 helyileg tárolhatja őket egy gyorsan és egyszerűen lekérdezhető táblában. Ez azonban azt jelenti, hogy előfordulhat, hogy a helyi adatok nem az eredeti adatok legfrissebb verziói. Ezután futtasson egy másik folyamatot a helyi adatok rendszeres frissítéséhez. Ez a folyamat lehet folyamat Power Automate , 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 kell frissnek lenniük az adatoknak 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 van tárolva, amelyet egy egyéni összekötő API-ján keresztül érhet el. Tegyük fel azonban, hogy az API-hívás lassú, ezért úgy dönt, hogy másolja a termékadatokat, és helyileg tárolja őket egy táblában. Ezután létrehozhat egy nézetet, amely egyesíti a táblázatot az alkalmazás egyéb releváns adataival. Létrehoz egy Power Automate folyamatot is, amely minden nap fut, és frissíti a táblázatot az API legfrissebb termékadataival. Így az alkalmazás gyorsabban tudja lekérdezni a helyi adatokat, és az adatok legfeljebb egy naposak.

Az adatok duplikálása gyakori technika a vállalati szintű alkalmazásokban a jó teljesítmény biztosítása érdekében. Beépülő modulok, tárolt eljárások vagy adatáthelyezés használatával Dataverse duplikálhatja az adatokat egyetlen, lekérdezésre optimalizált táblába. A kulcskérdés az, hogy mennyire kell naprakésznek lenniük ezeknek az adatoknak? Ha megengedhet magának némi késést, ezzel a technikával felgyorsíthatja az alkalmazást.

Javaslatok

E cél eléréséhez fontolja meg a következő kérdéseket és javaslatokat:

1. Mennyire fontos, hogy az ügyfél lássa az adatértéket egy katalógusban vagy adatrácsban? Elfogadható lenne, ha először kiválasztanánk egy rekordot, majd megjelenítenénk az adatokat egy űrlapon?
2. El tudja végezni egy nézet az adatok megfelelő formátumban való megjelenítéséhez szükséges előkészítést?
3. Olyan "IN" operátort használ, ahol a "StartsWith" működni fog?
4. Mennyire kell naprakésznek lenniük az adatoknak? Van olyan adatduplikációs stratégia, amellyel a lekérdezés alapértelmezés szerint egyetlen táblán működik?