Share via


Geoptimaliseerde querygegevenspatronen

Het eenvoudigste en snelste gegevensquerypatroon is:

  1. Een enkele tabel of weergave
  2. Voorgefilterd op de server naar wat u nodig hebt
  3. Kolommen worden correct geïndexeerd voor de verwachte query's

Wanneer u uw app ontwerpt, moet u nadenken over hoe u de gegevens snel kunt opvragen. De beste manier om gegevens op te vragen is door één tabel of weergave te gebruiken die alle informatie bevat die u nodig heeft, en deze op de server te filteren voordat u deze in uw app weergeeft. U moet er ook voor zorgen dat de kolommen die u gebruikt om de gegevens te filteren of te sorteren, correct zijn geïndexeerd. Dit maakt uw app sneller en soepeler.

Stel dat u over een galerie beschikt met een lijst met klanten en hun verkopers. Als u de klant- en verkopergegevens in afzonderlijke tabellen opslaat, moet u zoekopdrachten gebruiken om de naam van de verkoper voor elke klant te achterhalen. Dit vertraagt ​​uw app omdat deze veel query's naar de andere tabel moet uitvoeren. Een betere manier is om een ​​weergave te maken die de klant- en verkoperinformatie in één tabel combineert, en die weergave te gebruiken als de gegevensbron voor uw galerie. Dan hoeft uw app slechts één query uit te voeren om alle benodigde gegevens te verkrijgen.

Er is een wisselwerking tussen de snelheid van query's en de normalisatie van gegevens. Datanormalisatie betekent dat u de gegevens slechts één keer opslaat en duplicatie vermijdt. Dit helpt om de gegevens consistent en accuraat te houden. Soms moet u echter bepaalde gegevens dupliceren om de query's en sneller en eenvoudiger te maken. U moet deze twee doelen in evenwicht brengen in uw app-ontwerp en tabelstructuur. Anders zal uw app traag zijn, omdat deze veel werk moet verzetten om de gegevens uit verschillende tabellen te filteren en samen te voegen.

Server-side weergaven gebruiken

Weergaven zijn waarschijnlijk het meest gebruikte instrument om deze doelstellingen in evenwicht te brengen. Ze presenteren een enkele tabelstructuur voor query's, filteren gegevens vooraf op wat u nodig hebt in de query, maken zoekopdrachten en samenvoeging met andere tabellen mogelijk. Omdat de filters, zoekopdrachten en samenvoegingen voor de weergave op de server worden berekend, worden zowel de nettolading als de rekenkracht aan de clientzijde geminimaliseerd.

Een galerie kan veel records van een gegevensbron weergeven. Maar soms moet u aanvullende informatie tonen van een andere gegevensbron die gerelateerd is aan de originele. U hebt bijvoorbeeld een galerie met een lijst met klanten, en u wilt de naam weergeven van de verkoper die aan elke klant is toegewezen. De naam van de verkoper wordt opgeslagen in een andere gegevensbron dan de gegevens van de klant. Om de naam van de verkoper weer te geven, moet u een zoekopdrachtfunctie gebruiken die de overeenkomende record in de andere gegevensbron vindt. Hiermee wordt de oorspronkelijke tabel uitgebreid met de zoekwaarden.

Het uitbreiden van de tabel kan echter erg traag zijn als u veel records en veel zoekopdrachten heeft. Voor elke record in de galerie moet de app een afzonderlijke query uitvoeren op de andere gegevensbron en de opzoekwaarde ophalen. Dit betekent dat de app mogelijk veel query's voor elke record moet uitvoeren, wat lang kan duren en de prestaties van de app kan beïnvloeden. Dit antipatroon wordt ook wel 'N kwadraat, (n^2)' of een 'N+1'-probleem genoemd.

StartsWith of Filter gebruiken

Power Fx biedt verschillende manieren om gegevens te doorzoeken. Gebruik in het algemeen een expressie die gebruikmaakt van een index, zoals StartsWith of Filter in plaats van één die de hele tabel als In leest. De operator In is prima voor verzamelingen in het geheugen of als de externe gegevensbrontabel erg klein is.

Overweeg gegevensduplicatie

Soms zijn gegevens traag toegankelijk in een query, omdat deze op een andere locatie of in een andere indeling zijn opgeslagen. Om de query sneller te maken, kunt u de langzame gegevens kopiëren en lokaal opslaan in een tabel die snel en gemakkelijk op te zoeken is. Dit betekent echter dat de lokale gegevens mogelijk niet de meest bijgewerkte versie van de oorspronkelijke gegevens zijn. Voer vervolgens een ander proces uit om de lokale gegevens periodiek bij te werken. Dit proces kan een Power Automate-stroom, een invoegtoepassing, een opgeslagen procedure of een andere methode zijn die gegevens van de ene plek naar de andere verplaatst.

De frequentievereiste voor het bijwerken van de lokale gegevens is afhankelijk van uw zakelijke behoeften. Hoe actueel moeten de gegevens voor uw app zijn? Stel dat u voor Contoso werkt, een bedrijf dat fietsen verkoopt. De lijst met beschikbare fietsen wordt opgeslagen in een productendatabase waartoe u via een API in een aangepaste connector toegang kunt krijgen. Maar stel dat de API-aanroep langzaam is, en dus besluit u de productgegevens te kopiëren en lokaal in een tabel op te slaan. Vervolgens maakt u een weergave die uw tabel combineert met andere relevante gegevens voor uw app. Ook maakt u een Power Automate-stroom die elke dag draait en uw tabel bijwerkt met de nieuwste productgegevens uit de API. Dan kan uw app de lokale gegevens sneller opvragen, en zijn de gegevens maximaal één dag oud.

Het dupliceren van gegevens is een veelgebruikte techniek in bedrijfsapplicaties om goede prestaties te garanderen. U kunt gebruikmaken van Dataverse-invoegtoepassingen, opgeslagen procedures of gegevensverplaatsing om gegevens te dupliceren in één enkele tabel die is geoptimaliseerd voor query's. De hamvraag is: hoe actueel moeten deze gegevens zijn? Als u zich wat vertraging kunt veroorloven, kunt u deze techniek gebruiken om uw app te versnellen.

Suggesties

Om dit doel te bereiken, kunt u de volgende vragen en suggesties overwegen:

  1. Hoe belangrijk is het voor een klant om de gegevenswaarde in een galerie of gegevensraster te zien? Zou het acceptabel zijn om eerst een record te selecteren en de gegevens vervolgens in een formulier weer te geven?
  2. Kan een weergave het voorwerk doen dat nodig is om gegevens in het juiste formaat te zien?
  3. Gebruikt u een "IN"-operator waarbij een "StartsWith" werkt?
  4. Hoe actueel moeten uw gegevens zijn? Is er een strategie voor gegevensduplicatie die u kunt gebruiken om uw query standaard via één tabel te laten werken?