Optimoidut kyselyn tietomallit
Yksinkertaisin ja nopein tietojen kyselymalli on seuraava:
- Yksi taulukko tai näkymä
- Esisuodatettu palvelimella sen mukaan, mitä tarvitaan
- Sarakkeet indeksoidaan oikein odotettavissa olevia kyselyjä varten
Kun suunnittelet sovellusta, mieti, miten tiedoista voidaan tehdä kysely nopeasti. Paras tapa tehdä tiedoista kysely on käyttää yhtä taulukkoa tai näkymää, jossa on kaikki tarvitut tiedot, ja suodattaa ne palvelimella ennen tietojen näyttämistä sovelluksessa. Varmista myös, että tietojen suodattamisessa ja lajittelussa käytettävät sarakkeet on indeksoitu oikein. Tämä tekee sovelluksesta nopeamman ja sujuvamman.
Oletetaan esimerkiksi, että käytettävissä on valikoima, jossa on asiakkaiden ja heidän myyjiensä luettelo. Jos tallennat asiakkaan ja myyjän tiedot erillisiin taulukoihin, sinun on käytettävä hakuja noutaaksesi kunkin asiakkaan myyjän nimen. Tämä hidastaa sovellusta, koska sen on suoritettava useita kyselyitä toisessa taulukossa. Parempi tapa on luoda näkymä, joka yhdistää asiakkaan ja myyjän tiedot yhteen taulukkoon, ja käyttää tätä näkymää valikoiman tietolähteenä. Tämän jälkeen sovelluksen on suoritettava vain yksi kysely, joka noutaa kaikki tarvittavat tiedot.
Kyselyn nopeuden ja tietojen normalisoinnin välillä on tehtävä kompromissi. Tietojen normalisointi tarkoittaa, että tallennat tiedot vain kerran ja vältät kaksoiskappaleet. Näin tiedot voidaan pitää johdonmukaisina ja tarkkoina. Joskus tietoja on kuitenkin kopioitava, jotta kyselyistä tulee nopeampia ja helpompia. Sovelluksen suunnittelussa ja taulukkorakenteessa on tasapainoteltava näiden kahden tavoitteen välillä. Muussa tapauksessa sovelluksesta tulee hidas ja se aiheuttaa viiveitä, koska sen on tehtävä paljon töitä eri taulukoiden tietojen suodattamisessa ja yhdistämisessä.
Palvelinpuolen näkymien käyttö
Näkymät ovat luultavasti yleisin työkalu, joka auttaa näiden tavoitteiden välillä tasapainottelemisessa. Ne sisältävät yhden taulukkorakenteen kyselyille, esisuodattavat kyselyssä tarvittavat tiedot ja mahdollistavat muissa taulukoissa tehtävät haut ja liitokset. Koska näkymän suodattimet, haut ja liitokset lasketaan palvelimella, sekä tiedot että asiakaspuolen laskenta on minimoitu.
Liiallisten hakujen välttäminen valikoimassa
Valikoima voi näyttää liian monta tietuetta tietolähteestä. Joskus toisesta, alkuperäiseen liittyvästä tietolähteestä on kuitenkin näytettävä lisätietoja. Esimerkkinä voidaan ajatella valikoimaa, jossa näkyy asiakasluettelo. Valikoimassa halutaan näyttää myös asiakkaalle liitetyn myyjän nimi. Myyjän nimi on tallennettu eri tietolähteeseen kuin asiakkaan tiedot. Myyjän nimen näyttämiseksi on käytettävä hakutoimintoa, joka löytää vastaavan tietueen toisesta tietolähde:stä. Tämä laajentaa alkuperäisen taulukon hakuarvoilla.
Taulukon laajentaminen voi kuitenkin olla hyvin hidasta, jos tietueita ja hakuja on paljon. Sovelluksen on suoritettava valikoiman jokaiselle tietueelle erillinen kysely toiselle tietolähde ja hankittava hakuarvo. Tämä tarkoittaa sitä, että sovellus saattaa joutua suorittamaan useita kyselyitä jokaiselle tietueelle. Tämä voi kestää kauan ja vaikuttaa sovelluksen suorituskykyyn. Tämä toimimaton malli tunnetaan myös nimellä N potenssiin (n^2) ja ongelmana N+1.
Käytössä StartsWith tai Filter
Power Fx tarjoaa useita tapoja tietojen hakuun. Yleisesti käytetään lauseketta, joka hyödyntää indeksiä kuten StartsWith tai Filter sellisen lausekkeen sijaan, jossa luetaan koko taulukko, kuten In. In-operaattori sopii hyvin muistissa oleviin kokoelmiin ja silloin, kun ulkoisen tietolähteen taulukko on erittäin pieni.
Tietojen kopioiminen
Joskus tietojen käyttö kyselyssä on hidasta, koska tiedot on tallennettu eri sijaintiin tai ne ovat eri muodossa. Voit nopeuttaa kyselyä kopioimalla hitaat tiedot ja tallentamalla ne paikalliseen taulukkoon, josta kyselyn tekeminen on nopeaa ja helppoa. Tämä tarkoittaa kuitenkin sitä, että paikalliset tiedot eivät välttämättä ole alkuperäisten tietojen uusin versio. Suorita sitten toinen prosessi päivittääksesi paikalliset tiedot säännöllisesti. Tämä prosessi voi olla Power Automate-työnkulku, laajennus, tallennettu toimintosarja tai mikä tahansa muu menetelmä, joka voi siirtää tietoja paikasta toiseen.
Paikallisten tietojen päivitystiheys riippuu yrityksen tarpeista. Miten päivitettyjä tietojen tulee olla sovellusta varten? Ajatellaan, että työskentelet Contosossa, joka on polkupyöriä myyvä yritys. Saatavilla olevien polkupyörien luettelo on tallennettu tuotetietokantaan, jota voit käyttää ohjelmointirajapinnan kautta mukautetussa yhdistimessä. Mutta ohjelmointirajapintakutsu on hidas, ja päätät kopioida tuotetiedot ja tallentaa ne paikalliseen taulukkoon. Tämän jälkeen luodaan näkymä, joka yhdistää taulukon muiden sovelluksen olennaisten tietojen kanssa. Voit myös luoda joka päivä suoritettavan Power Automate -työnkulun, joka päivittää taulukkoon uusimmat tuotetiedot ohjelmointirajapinnasta. Tämän jälkeen sovellus voi tehdä kyselyn aiempaa nopeammin paikallisista tiedoista, ja tietojen päivityksestä on kulunut enintään yksi päivä.
Tietojen kopioiminen on yleinen tekniikka yritystason sovelluksissa hyvän suorituskyvyn varmistamiseksi. Voit käyttää Dataversen laajennuksia, tallennettuja toimintosarjoja ja tietojen siirtoa tietojen kopioimisessa yhteen taulukkoon, joka on optimoitu kyselyjä varten. Keskeinen kysymys on seuraava: Miten päivitettyjä tietojen tulee olla? Jos viive ei haittaa, voit käyttää tätä tekniikkaa sovelluksen nopeuttamiseksi.
Ehdotukset
Ota huomioon seuraavat kysymykset ja ehdotukset tämän tavoitteen saavuttamiseksi:
- Miten tärkeää on, että asiakas näkee tietojen arvon valikoimassa tai tietoruudukossa? Voiko tietueen valita ensin ja sitten näyttää tiedot lomakkeessa?
- Voiko näkymä tehdä tarvittavat esityöt tietojen näyttämiseksi oikeassa muodossa?
- Onko käytössä IN-operaattori, jossa StartsWith toimii?
- Kuinka päivitettyjä tietojen on oltava? Onko olemassa tietojen kopiointistrategia, jonka avulla kysely toimii oletusarvoisesti yhdessä taulukossa?