Оптимизированные шаблоны данных запросов

Самый простой и быстрый шаблон запроса данных:

1. Одна таблица или представление
2. Предварительно отфильтровано на сервере до того, что вам нужно
3. Столбцы индексируются правильно для ожидаемых запросов

Когда вы разрабатываете свое приложение, вам нужно подумать о том, как быстро запрашивать данные. Лучший способ запроса данных — использовать одну таблицу или представление, содержащее всю необходимую информацию, и фильтровать ее на сервере, прежде чем отображать в своем приложении. Вам также необходимо убедиться, что столбцы, которые вы используете для фильтрации или сортировки данных, проиндексированы правильно. Это делает ваше приложение более быстрым и плавным.

Например, предположим, что у вас есть коллекция, в которой показан список клиентов и их продавцов. Если вы храните информацию о клиентах и продавцах в отдельных таблицах, вам необходимо использовать поиск, чтобы получить имя продавца для каждого клиента. Это замедляет работу вашего приложения, поскольку ему приходится выполнять множество запросов к другой таблице. Лучший способ — создать представление, объединяющее информацию о клиентах и продавцах в одной таблице, и использовать это представление в качестве источника данных для своей коллекции. Тогда вашему приложению достаточно будет выполнить всего один запрос, чтобы получить все необходимые данные.

Существует компромисс между скоростью запросов и нормализацией данных. Нормализация данных означает, что вы сохраняете данные только один раз и избегаете дублирования. Это помогает поддерживать согласованность и точность данных. Однако иногда вам необходимо дублировать некоторые данные, чтобы сделать запросы быстрее и проще. Вам необходимо сбалансировать эти две цели в дизайне вашего приложения и структуре таблиц. В противном случае ваше приложение будет работать медленно и с задержками, поскольку ему придется выполнять большую работу по фильтрации и объединению данных из разных таблиц.

Используйте представления на стороне сервера

Представления, вероятно, являются наиболее распространенным инструментом, помогающим сбалансировать эти цели. Они представляют единую структуру таблицы для запросов, предварительно фильтруют данные для того, что вам нужно в запросе, а также позволяют осуществлять поиск и соединение с другими таблицами. Поскольку фильтры, поиски и соединения для представления вычисляются на сервере, как полезная нагрузка, так и вычисления на стороне клиента сводятся к минимуму.

Избегайте слишком большого количества поисков в коллекции

В коллекции может отображаться множество записей из источника данных. Но иногда вам нужно показать дополнительную информацию из другого источника данных, связанного с исходным. Например, у вас есть коллекция, в которой отображается список клиентов, и вы хотите отображать имя продавца, назначенного каждому клиенту. Имя продавца хранится в источнике данных, отличном от информации о покупателе. Чтобы отобразить имя продавца, вам необходимо использовать функцию поиска, которая находит соответствующую запись в другом источнике данных. Это расширяет исходную таблицу искомыми значениями.

Однако расширение таблицы может быть очень медленным, если у вас много записей и много запросов. Для каждой записи в коллекции приложению необходимо выполнить отдельный запрос к другому источнику данных и получить искомое значение. Это означает, что приложению может потребоваться выполнить множество запросов для каждой записи, что может занять много времени и повлиять на производительность приложения. Этот неблагоприятный шаблон иногда называют проблемой «N в квадрате (n^2)» или «N+1».

Использование StartsWith или Filter

Power Fx предоставляет несколько способов поиска данных. В общем случае используйте выражение, которое использует индекс, например StartsWith или Filter, вместо того, которое читает всю таблицу, например In. Оператор In подходит для коллекций в памяти или если таблица во внешнем источнике данных очень мала.

Рассмотрите возможность дублирования данных

Иногда доступ к данным в запросе происходит медленно, поскольку они хранятся в другом месте или формате. Чтобы ускорить запрос, вы можете скопировать медленные данные и сохранить их локально в таблице, к которой можно быстро и легко выполнить запрос. Однако это означает, что локальные данные могут не быть самой последней версией исходных данных. Затем запустите другой процесс для периодического обновления локальных данных. Этот процесс может представлять собой поток Power Automate, подключаемый модуль, хранимую процедуру или любой другой метод, который может перемещать данные из одного места в другое.

Требование к частоте обновления локальных данных зависит от потребностей вашего бизнеса. Насколько свежими должны быть данные для вашего приложения? Например, предположим, что вы работаете в Contoso, компании, которая продает велосипеды. Список доступных велосипедов хранится в базе данных продуктов, к которой вы можете получить доступ через API в пользовательском соединителе. Но предположим, что вызов API выполняется медленно, и вы решили скопировать данные о продукте и сохранить их локально в таблице. Затем вы создаете представление, которое объединяет вашу таблицу с другими соответствующими данными для вашего приложения. Вы также создаете поток Power Automate, который запускается каждый день и обновляет вашу таблицу последними данными о продуктах из API. Тогда ваше приложение сможет быстрее запрашивать локальные данные, а возраст данных не превышает одного дня.

Дублирование данных — распространенный метод в приложениях корпоративного уровня, обеспечивающий хорошую производительность. Вы можете использовать подключаемые модули Dataverse, хранимые процедуры или перемещение данных для дублирования данных в одну таблицу, оптимизированную для запросов. Ключевой вопрос: насколько актуальными должны быть эти данные? Если вы можете позволить себе некоторую задержку, вы можете использовать этот метод, чтобы ускорить работу вашего приложения.

Предложения

Для достижения этой цели рассмотрите следующие вопросы и предложения:

1. Насколько важно для клиента видеть значение данных в коллекции или сетке данных? Допустимо ли сначала выбрать запись, а затем отобразить данные в форме?
2. Может ли представление выполнить предварительную работу, необходимую для просмотра данных в правильном формате?
3. Используете ли вы оператор «IN» там, где будет работать «StartsWith»?
4. Насколько актуальными должны быть ваши данные? Существует ли стратегия дублирования данных, которую вы можете использовать, чтобы ваш запрос по умолчанию работал с одной таблицей?