Zoptymalizowane wzorce danych zapytań

Najprostszym i najszybszym wzorcem zapytań dotyczących danych jest:

1. Pojedyncza tabela lub widok
2. Wstępnie przefiltrowane na serwerze według potrzeb
3. Kolumny są prawidłowo indeksowane dla oczekiwanych zapytań

Podczas projektowania aplikacji należy zastanowić się, jak szybko wykonywać zapytania dotyczące danych. Najlepszym sposobem wykonywania zapytań o dane jest użycie pojedynczej tabeli lub widoku zawierającego wszystkie potrzebne informacje i filtrowanie ich na serwerze przed wyświetleniem ich w aplikacji. Należy również upewnić się, że kolumny używane do filtrowania lub sortowania danych są prawidłowo indeksowane. Dzięki temu aplikacja jest szybsza i bezproblemowa.

Załóżmy na przykład, że masz galerię zawierającą listę klientów i ich sprzedawców. Jeśli przechowujesz informacje o kliencie i sprzedawcy w osobnych tabelach, musisz użyć odnośników, aby uzyskać nazwę sprzedawcy dla każdego klienta. Spowalnia to aplikację, ponieważ musi uruchamiać wiele zapytań w drugiej tabeli. Lepszym sposobem jest utworzenie widoku, który łączy informacje klienta i sprzedawcy w jednej tabeli i użyj tego widoku jako źródła danych dla galerii. Następnie aplikacja musi uruchomić tylko jedno zapytanie, aby pobrać wszystkie potrzebne dane.

Istnieje kompromis między szybkością zapytań a normalizacją danych. Normalizacja danych oznacza, że dane są przechowywane tylko raz, co pozwala uniknąć duplikowania. Pomaga to zachować spójność i dokładność danych. Jednak czasami trzeba zduplikować niektóre dane, aby przyspieszyć i ułatwić wykonywanie zapytań. Te dwa cele należy zrównoważyć w strukturze projektu aplikacji i tabeli. W przeciwnym razie aplikacja będzie wolna i opóźniona, ponieważ musi wykonywać wiele operacji, aby filtrować i łączyć dane z różnych tabel.

Korzystanie z widoków po stronie serwera

Prawdopodobnie najbardziej typowym narzędziem, które pomoże zrównoważyć te cele, są widoki. Przedstawiają one jedną strukturę tabeli dla zapytań, wstępne filtrowanie danych dla elementów potrzebnych w zapytaniu oraz umożliwiają wyszukiwanie i łączenia z innymi tabelami. Ponieważ filtry, wyszukiwania i sprzężenia dla widoku są obliczane na serwerze, zarówno ładunek, jak i obliczenia po stronie klienta są zminimalizowane.

Unikaj zbyt wielu wyszukiwań w galerii

Galeria może wyświetlać wiele rekordów ze źródła danych. Czasami jednak trzeba wyświetlić dodatkowe informacje z innego źródła danych powiązanego z oryginalnym. Na przykład masz galerię zawierającą listę klientów i chcesz wyświetlić nazwę sprzedawcy przypisanego do każdego klienta. Nazwa sprzedawcy jest przechowywana w innym źródle danych niż informacje o kliencie. Aby wyświetlić nazwę sprzedawcy, należy użyć funkcji odnośnika, która znajduje pasujący rekord w innym źródle danych. Powoduje to rozszerzenie oryginalnej tabeli przy użyciu wartości wyszukiwania.

Jednak rozszerzanie tabeli może być bardzo powolne, jeśli masz wiele rekordów i wiele odnośników. Dla każdego rekordu w galerii aplikacja musi uruchomić oddzielne zapytanie do innego źródła danych i uzyskać wartość wyszukiwania. Oznacza to, że aplikacja może wymagać uruchomienia wielu zapytań dla każdego rekordu, co może zająć dużo czasu i wpłynąć na wydajność aplikacji. Ten antywzór jest czasami nazywany problemem „N do kwadratu, (n^2)” lub problemem „N+1”.

Używanie funkcji StartsWith lub Filter

Power Fx oferuje kilka sposobów wyszukiwania danych. Ogólnie rzecz biorąc, należy użyć wyrażenia, które korzysta z indeksu, takiego jak StartsWith lub Filter , zamiast jednego, który odczytuje całą tabelę, taką jak In. Operator In jest odpowiedni dla kolekcji w pamięci lub jeśli zewnętrzna tabela źródła danych jest bardzo mała.

Rozważ duplikowanie danych

Czasami dostęp do danych w zapytaniu jest powolny, ponieważ jest przechowywany w innej lokalizacji lub formacie. Aby przyspieszyć wykonywanie zapytań, możesz skopiować powolne dane i zapisać je lokalnie w tabeli, która jest szybka i łatwa w zapytaniu. Oznacza to jednak, że dane lokalne mogą nie być najbardziej zaktualizowaną wersją oryginalnych danych. Następnie uruchom inny proces, aby okresowo aktualizować dane lokalne. Ten proces może być przepływem usługi Power Automate, dodatkiem plug-in, procedurą składowaną lub inną metodą, która może przenosić dane z jednego miejsca do innego.

Częstotliwość aktualizowania danych lokalnych zależy od potrzeb biznesowych. Jak świeże są dane potrzebne dla twojej aplikacji? Załóżmy na przykład, że pracujesz dla firmy Contoso, która sprzedaje rowery. Lista dostępnych rowerów jest przechowywana w bazie danych Products, do której można uzyskać dostęp za pośrednictwem interfejsu API w łączniku niestandardowym. Załóżmy jednak, że wywołanie interfejsu API działa wolno, dlatego decydujesz się skopiować dane produktu i zapisać je lokalnie w tabeli. Następnie utworzysz widok, który łączy tabelę z innymi odpowiednimi danymi dla aplikacji. Tworzysz również przepływ Power Automate, który uruchamia się codziennie i aktualizuje tabelę za pomocą najnowszych danych produktów z interfejsu API. Następnie aplikacja może szybciej wykonywać zapytania dotyczące danych lokalnych, a dane mają maksymalnie jeden dzień.

Duplikowanie danych jest typowym typem techniki w aplikacjach klasy korporacyjnej w celu zapewnienia dobrej wydajności. Możesz użyć wtyczek usługi Dataverse, procedur składowanych lub przenoszenia danych, aby zduplikować dane do pojedynczej tabeli zoptymalizowanej pod kątem wykonywania zapytań. Najważniejsze pytanie brzmi: jak aktualne muszą być te dane? Jeśli możesz sobie pozwolić na pewne opóźnienie, możesz użyć tej techniki, aby przyspieszyć aplikację.

Suggestions

Aby osiągnąć ten cel, rozważ następujące pytania i sugestie:

1. Jak ważne jest, aby klient widział wartość danych w galerii lub siatce danych? Czy najpierw można wybrać rekord, a następnie wyświetlić dane w formularzu?
2. Czy widok może wykonywać wstępne zadania niezbędne do wyświetlania danych w odpowiednim formacie?
3. Czy używasz operatora „IN”, w którym będzie działać „StartsWith”?
4. Jak aktualne muszą być twoje dane? Czy istnieje strategia duplikowania danych, której można użyć, aby zapytanie działało domyślnie nad pojedynczą tabelą?