Запити в динамічних списках

Приклад.

НЕПРАВИЛЬНО

ПРАВИЛЬНО

Область застосування: керований застосунок.

Методична рекомендація (корисна порада)

Під час проєктування динамічних списків у формах слід враховувати, що динамічні списки висувають вищі вимоги до швидкості виконання запитів, ніж в інших випадках (наприклад, у звітах, у процедурах обробки даних тощо). Дані в динамічних списках безпосередньо відображаються користувачеві, тому швидкість виведення та оновлення даних є критичною. У цій статті перелічено рекомендації, що доповнюють загальні відомості щодо оптимізації запитів (див. групу статей «Оптимізація запитів»).

1. Потрібно намагатися робити прості запити для динамічних списків. Для цього насамперед потрібно оптимізувати архітектуру зберігання даних, щоб їх було просто відображати в динамічних списках.

Приклад.

У динамічному списку документів-розпоряджень на відвантаження потрібно вивести стан відвантаження. Стан залежить від залишків регістру накопичення та статусів двох документів іншого типу.

НЕПРАВИЛЬНО

Намагатися розробити запит для динамічного списку, який враховуватиме всю складну логіку розрахунку стану відвантаження.

ПРАВИЛЬНО

Створити регістр відомостей «Стани відвантаження», у якому зберігати вже розрахований стан відвантаження. При цьому розрахунок можна робити або в процесі проведення документів, які можуть впливати на стан відвантаження, або окремим регламентним завданням.

2. Необхідно вибрати один із трьох режимів роботи динамічного списку:

• Динамічне зчитування даних увімкнено (рекомендується). Використовуються запити, що вибирають записи в кількості, приблизно відповідній кількості видимих рядків у таблиці.
• Динамічне зчитування даних вимкнено, задано основну таблицю. Використовуються запити, що вибирають по 1000 записів у буфер на сервері, за потреби дані передаються на клієнт. Менш ефективно, ніж динамічне зчитування
• Динамічне зчитування даних вимкнено, основну таблицю не задано. Запит виконується «як є». У буфері накопичуються дані, починаючи з 1000 записів. Що ближче до кінця списку, то більше записів. Можна використовувати лише для завідомо малих вибірок.

3. Під час розробки динамічного списку слід враховувати, що запит, який фактично буде сформований до СУБД, залежить від попередньо визначених налаштувань відборів, порядку та групування СКД. Зокрема це означає, що необхідно розглянути індексування полів:

• За якими виконується з'єднання в запиті.
• На які накладено умови в запиті.
• Виведених як швидкі відбори.
• За якими виконується впорядкування або передбачено групування.
• За якими очікується, що користувач часто виконуватиме впорядкування (групування).

При цьому не слід індексувати всі поля поспіль «про всяк випадок», оскільки надлишкові індекси створюють невиправдане навантаження під час запису даних.

Див. також: Невідповідність індексів і умов запиту, Обмеження під час використання динамічних списків

4. Наполегливо не рекомендується використовувати конструкції, що «обтяжують» запит:

• конструкції РІЗНІ та ЗГРУПУВАТИ ЗА;
• конструкції ВИБІР у реченні ДЕ або в умовах з'єднання;
• впорядкування за полем, отриманим за допомогою конструкції ВИБІР, зокрема й користувацьке.

Див. також: Загальні вимоги щодо розробки оптимальних запитів

5.1 З'єднуватися в запиті слід лише з невеликою кількістю реальних таблиць (в оптимальному варіанті в динамічному списку – лише одна таблиця, і вона призначена основною).

Не рекомендується виконувати з'єднання:

• з великою кількістю реальних таблиць. Орієнтуватися варто на кількість не більше 4 таблиць.
• із вкладеними запитами
• з віртуальними таблицями.

Див. також: Запити, що виконують з'єднання з вкладеними запитами або віртуальними таблицями

5.2. З'єднання з віртуальними таблицями допустиме в окремих випадках, якщо запит і архітектура даних задовольняють низку умов:

• допустиме з'єднання з віртуальними таблицями ЗрізОстанніх (ЗрізПерших), якщо регістр відомостей містить
  завідомо невелику кількість записів. Наприклад, отримання поточного курсу валют за даними регістру відомостей КурсиВалют;
• під час звернення до віртуальної таблиці будуть використані збережені підсумки регістру відомостей (див. Дозвіл підсумків для періодичних регістрів відомостей)
• запит до віртуальної таблиці Залишки буде перетворено платформою на просте читання збереженої таблиці підсумків без групувань (див. Ефективне звернення до віртуальної таблиці «Залишки»)

5.3. Під час обліку кількості таблиць, що беруть участь у запиті, необхідно пам'ятати, що звернення до полів «через крапку» призводить до неявного з'єднання з додатковими таблицями. Докладніше див.: Розіменування посилальних полів складеного типу в мові запитів

5.4 Під час роботи зі списком з неповними правами, у яких налаштовано обмеження доступу до даних (RLS) до таблиць, що беруть участь у запиті*, також автоматично приєднуються умови обмеження доступу до даних, які уповільнюють роботу списку. Саме в цьому режимі роботи слід перевіряти швидкість роботи динамічних списків.

6. Передбачити оптимізацію під час роботи з полями складеного типу

• Під час використання в з'єднаннях, відборах, упорядкуванні та інших конструкціях складеного поля необхідно, щоб склад типів цього поля визначався лише посилальними типами. Докладніше див.: Обмеження на використання реквізитів складеного типу.
• Якщо заздалегідь відомо, якого типу має бути отримано поле складеного типу, то його необхідно виражати. Наприклад:

ВИРАЗИТИ(ДаніДокумента.ДокументПідстава ЯК Документ.АктВиконанихРобіт)

Див. також: Розіменування посилальних полів складеного типу в мові запитів

7. Запит динамічного списку рекомендується змінювати «на льоту» на більш оптимальний, якщо це можливо.
Наприклад, під час встановлення швидкого відбору за полем складеного типу рекомендується змінити запит динамічного списку, виразивши це поле.

8. Якщо застосування вищевикладених рекомендацій неможливе або воно не дає належного ефекту, то можна розглянути такі шляхи оптимізації:

8.1. Відмовитися від частини можливостей динамічного списку.

Наприклад:

• Від виведення не настільки значущої інформації, отримання якої призводить до ускладнення запиту.
• Від реалізованих сервісних можливостей щодо групування списку.

8.2. Здійснювати виведення даних не в динамічний список, а в таблицю або дерево значень.

При цьому з'являться можливості оптимізації, недоступні для динамічних списків, такі як використання тимчасових таблиць, пакетних запитів, привілейованого режиму тощо.

Цей спосіб застосовний, якщо виконується одна з умов:

• Вихідних даних завідомо мало (десятки-сотні записів).
• Обов'язкові відбори, що накладаються на список, гарантують, що даних в один момент часу виводиться мало записів.
• Порційність виведення даних організована іншими засобами (вручну), наприклад, як у результатах повнотекстового пошуку.