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

Див. також

1.1 У мові запитів можна звертатися не тільки до полів вихідних таблиць запиту, перелічених у реченні З, а й до полів таблиці, на яку посилається поле вихідної таблиці запиту, якщо це поле має посилальний тип. Імена полів при цьому пишуться "через крапку". Застосування такої конструкції призводить до неявного з'єднання з додатковими таблицями для отримання значень полів "через крапку".

Наприклад, у запиті

ВЫБРАТЬ 
ТоварныеЗапасы.Товар КАК Товар, 
ТоварныеЗапасы.Количество КАК Количество, 
ТоварныеЗапасы.Товар.Артикул КАК Артикул 
ИЗ 
РегистрНакопления.ТоварныеЗапасы КАК ТоварныеЗапасы 
...

крім явно зазначеної у реченні З таблиці РегистрНакопления.ТоварныеЗапасы неявно бере участь таблиця Справочник.Товары для отримання значення поля Артикул. А у разі використання обмежень доступу на рівні записів (RLS), до запиту додаються ще й таблиці, що беруть участь у RLS до таблиці Справочник.Товары.

1.2 Велика кількість вихідних таблиць запиту призводить до його ускладнення та може значно збільшувати час його виконання. Особливо важливо пам'ятати про це в тих випадках, коли поле таблиці посилального типу має складовий тип і може містити посилання на кілька таблиць. У такому разі отримання полів інших таблиць "через крапку" від такого поля складового типу призведе до з'єднання з усіма таблицями, посилання на які можуть опинитися в цьому полі, і до RLS цих таблиць.

Наприклад, у наведеному нижче запиті отримання дати реєстратора призведе до неявного з'єднання з таблицями всіх документів — реєстраторів регістру ТоварныеЗапасы

ВЫБРАТЬ 
... 
ТоварныеЗапасы.Регистратор.Дата, 
... 
ИЗ 
РегистрНакопления.ТоварныеЗапасы КАК ТоварныеЗапасы 
...

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

2.1 Слід уникати надмірності під час створення полів складових посилальних типів. Необхідно зазначати рівно стільки можливих типів для цього поля, скільки потрібно. Не слід без потреби використовувати типи "будь-яке посилання" або "посилання на будь-який документ" тощо.

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

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

Наприклад, у регістрі ТоварныеЗапасы можна створити реквізит ДатаРегистратора, заповнювати його під час проведення документів і використовувати потім у запитах:

ВЫБРАТЬ 
... 
ТоварныеЗапасы.ДатаРегистратора, 
... 
ИЗ 
РегистрНакопления.ТоварныеЗапасы КАК ТоварныеЗапасы 
...

Це призведе до дублювання інформації та деякого (незначного) збільшення її обсягу, але може суттєво підвищити продуктивність і стабільність роботи запиту.

2.3 За потреби слід жертвувати компактністю та універсальністю коду заради продуктивності:

• Як правило, для виконання конкретного запиту в цих умовах не потрібні всі можливі типи цього посилання. У такому разі слід обмежити кількість можливих типів за допомогою функції ВЫРАЗИТЬ.
• Якщо цей запит є універсальним і використовується в кількох різних ситуаціях (де типи посилання можуть бути різними), то можна формувати запит динамічно, підставляючи у функцію ВЫРАЗИТЬ той тип, який потрібен за цих умов.

Це збільшить обсяг вихідного коду і, можливо, зробить його менш універсальним, але може суттєво підвищити продуктивність і стабільність роботи запиту.

Наприклад, неправильно:

Запрос.Текст = "ВЫБРАТЬ
| Продажи.Регистратор.Номер,
| Продажи.Регистратор.Дата,
| Продажи.Контрагент,
| Продажи.Количество,
| Продажи.Стоимость
|ИЗ
| РегистрНакопления.Продажи КАК Продажи
|ГДЕ ...

У цьому запиті використовується звернення до реквізитів реєстратора. Реєстратор є полем складового типу, яке може набувати значень посилання на один із 56 видів документів.
SQL-текст цього запиту міститиме 56 лівих з'єднань із таблицями документів. Це може призвести до серйозних проблем продуктивності під час виконання запиту.

Правильно:

Для розв'язання цього конкретного завдання немає потреби з'єднуватися з усіма 56 видами документів. Умови запиту такі, що під час його виконання буде вибрано лише рухи документів РеализацияТоваровУслуг та ЗаказыПокупателя. У цьому разі можна значно прискорити роботу запиту, обмеживши кількість з'єднань за допомогою функції ВЫРАЗИТЬ().

Запрос.Текст = "ВЫБРАТЬ
| ВЫБОР
| КОГДА Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.РеализацияТоваровУслуг).Номер
| КОГДА Продажи.Регистратор ССЫЛКА Документ.ЗаказПокупателя
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ЗаказПокупателя).Номер
| КОНЕЦ ВЫБОРА КАК Номер,
| ВЫБОР
| КОГДА Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.РеализацияТоваровУслуг).Дата
| КОГДА Продажи.Регистратор ССЫЛКА Документ.ЗаказПокупателя
| ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ЗаказПокупателя).Дата
| КОНЕЦ ВЫБОРА КАК Дата,
| Продажи.Контрагент,
| Продажи.Количество,
| Продажи.Стоимость
|ИЗ
| РегистрНакопления.Продажи КАК Продажи
|ГДЕ
| Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг
| ИЛИ Продажи.Регистратор ССЫЛКА Документ.ЗаказыПокупателя";

Цей запит є більш громіздким і, можливо, менш універсальним (він не працюватиме правильно для інших ситуацій — коли можливі інші значення типів реєстратора). Однак під час його виконання буде сформовано SQL-запит, який міститиме лише два з'єднання з таблицями документів. Такий запит працюватиме значно швидше й стабільніше, ніж запит у його початковому вигляді.

Див. також

• Самодостатність регістрів