Padrões de dados de consulta otimizados

O padrão de consulta de dados mais simples e rápido é:

1. Uma tabela ou vista única
2. Pré-filtrado no servidor para o que precisa
3. As colunas são indexadas corretamente para as consultas esperadas

Ao projetar a sua aplicação, precisa de pensar em como consultar os dados rapidamente. A melhor maneira de consultar dados é usar uma única tabela ou vista que contenha todas as informações necessárias e filtrá-las no servidor antes de as apresentar na sua aplicação. Também precisa de se certificar de que as colunas usadas para filtrar ou classificar os dados são indexadas corretamente. Isto torna a sua aplicação mais rápida e suave.

Por exemplo, suponha que tem uma galeria que mostra uma lista de clientes e respetivos representantes de vendas. Se armazenar as informações do cliente e do representante de vendas em tabelas separadas, precisará de usar procuras para obter o nome do representante de vendas de cada cliente. Isto torna a sua aplicação mais lenta porque precisa de executar muitas consultas na outra tabela. A melhor maneira é criar uma vista que combine as informações do cliente e do representante de vendas numa tabela e usar essa vista como a origem de dados para a sua galeria. Então, a sua aplicação só precisa de executar uma consulta para obter todos os dados de que necessita.

Há uma compensação entre a velocidade da consulta e a normalização dos dados. A normalização de dados significa que armazena os dados apenas uma vez e evita duplicação. Isto ajuda a manter os dados consistentes e precisos. Porém, às vezes, é necessário duplicar alguns dados para tornar as consultas mais rápidas e fáceis. Precisa de equilibrar estes dois objetivos no design da aplicação e na estrutura da tabela. Caso contrário, a sua aplicação ficará lenta porque precisará de realizar vários trabalhos para filtrar e unir os dados de diferentes tabelas.

Usar vistas do lado do servidor

As vistas são, provavelmente, a ferramenta mais comum para ajudar a equilibrar estes objetivos. Apresentam uma estrutura de tabela única para consultas, pré-filtram os dados de acordo com o que precisa na consulta e permitem procuras e uniões a outras tabelas. Como os filtros, procuras e uniões da vista são computados no servidor, tanto o payload como a computação do lado do cliente são minimizados.

Evite demasiadas procuras numa galeria

Uma galeria pode apresentar muitos registos de uma origem de dados. Mas, por vezes, é necessário mostrar informações adicionais de outra origem de dados relacionada ao original. Por exemplo, tem uma galeria que mostra uma lista de clientes e pretende mostrar o nome do representante de vendas atribuído a cada cliente. O nome do representante de vendas é armazenado numa origem de dados diferente da das informações do cliente. Para mostrar o nome do representante de vendas, precisa de usar uma função de procura que encontra o registo correspondente na outra origem de dados. Isto expande a tabela original com os valores da procura.

No entanto, a expansão da tabela pode ser muito lenta se tiver muitos registos e muitas procuras. Para cada registo na galeria, a aplicação precisa de executar uma consulta separada para o outra origem de dados e obter o valor da procura. Isto significa que a aplicação pode precisar de executar muitas consultas para cada registo, o que pode demorar muito tempo e afetar o desempenho da aplicação. Por vezes, este antipadrão é conhecido como o problema "N ao quadrado, (n ^2)" ou "N+1".

Usar StartsWith ou Filter

O Power Fx fornece várias maneiras de pesquisar dados. Em geral, use uma expressão que tire partido de um índice, como StartsWith ou Filter, em vez de um que leia a tabela inteira, como In. O operador In é adequado para coleções na memória ou se a tabela de origem de dados externa for muito pequena.

Considere duplicar dados

Por vezes, o acesso aos dados numa consulta é lento porque estão armazenados numa localização ou formato diferente. Para tornar a consulta mais rápida, pode copiar os dados lentos e armazená-los localmente numa tabela que seja rápida e fácil de consultar. No entanto, isto significa que os dados locais podem não ser a versão mais atualizada dos dados originais. Em seguida, execute outro processo para atualizar os dados locais periodicamente. Este processo pode ser um fluxo do Power Automate, um plug-in, um procedimento armazenado ou qualquer outro método que possa mover dados de um lugar para outro.

O requisito de frequência de atualização dos dados locais depende das necessidades do seu negócio. Quão atualizados os dados precisam de ser para a sua aplicação? Por exemplo, suponha que trabalha para a Contoso, uma empresa que vende bicicletas. A lista de bicicletas disponíveis é armazenada numa base de dados de Produtos à qual pode aceder através de uma API num conector personalizado. Mas digamos que a chamada à API é lenta e decide copiar os dados do produto e armazená-los localmente numa tabela. Em seguida, cria uma vista que combina a sua tabela com outros dados relevantes para a sua aplicação. Também cria um fluxo do Power Automate que é executado todos os dias e atualiza a sua tabela com os dados do produto mais recentes da API. Em seguida, a sua aplicação pode consultar os dados locais mais depressa e os dados têm apenas um dia, no máximo.

A duplicação de dados é um tipo comum de técnica em aplicações de nível empresarial para garantir um bom desempenho. Pode usar plug-ins do Dataverse, procedimentos armazenados ou movimento de dados para duplicar dados numa única tabela otimizada para consulta. A questão-chave é: até que ponto estes dados têm de estar atualizados? Se puder aceitar algum atraso, poderá usar esta técnica para acelerar a sua aplicação.

Sugestões

Para atingir este objetivo, considere as seguintes perguntas e sugestões:

1. Quão importante é para um cliente ver o valor dos dados numa galeria ou grelha de dados? Seria aceitável primeiro selecionar primeiro um registo e depois mostrar os dados num formulário?
2. Uma vista pode fazer o trabalho prévio necessário para ver os dados no formato correto?
3. Está a usar um operador "IN" onde um "StartsWith" funcionará?
4. Quão atuais precisam de ser os seus dados? Existe uma estratégia de duplicação de dados que pode usar para que a sua consulta funcione numa única tabela por predefinição?