2. З'єднання з віртуальними таблицями

Якщо у запиті використовується з'єднання з віртуальною таблицею мови запитів 1С:Підприємства (наприклад, “ РеєстрНакопичення.Товари.Залишки() “) і запит працює із незадовільною продуктивністю, то рекомендується винести звернення до віртуальної таблиці в окремий запит із збереженням результатів у тимчасовій таблиці. Тобто, слід використовувати ту ж рекомендацію, що й у разі з'єднання з підзапитом (див. пункт 1).

Справа в тому, що віртуальні таблиці, які використовуються в мові запитів 1С:Підприємства, можуть розгортатися в підзапити під час трансляції в мову SQL. Це з тим, що віртуальна таблиця часто (але завжди) отримує дані з кількох фізичних таблиць СУБД. Якщо ви використовуєте з'єднання з віртуальною таблицею, то на рівні SQL воно може бути в деяких випадках реалізовано як з'єднання з підзапитом. У цьому випадку оптимізатор СУБД може так само вибрати неоптимальний план, як при роботі з підзапитом, використаним у мові 1С: Підприємства у явному вигляді.

3. Невідповідність індексів та умов запиту

Умови використовуються у наступних секціях запиту:

• ВИБРАТИ … З … ДЕ<условие>
• З'ЄДНАННЯ … ПО<условие>
• ВИБРАТИ … З<ВиртуальнаяТаблица>(, <условие>)
• МАЮЧІ<условие>

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

• Вимога 1. Індекс містить усі поля, перелічені в умові;
• Вимога 2. Ці поля знаходяться на початку індексу;
• Вимога 3. Ці поля йдуть поспіль, тобто з-поміж них «вклинюються» поля, які беруть участь у умови запиту;

Основні ідекси, що створюються 1С:Підприємством:

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

У випадках, коли автоматично створених індексів недостатньо, можна додатково проіндексувати реквізити об'єкта метаданих у конфігураторі. Однак, слід мати на увазі, що створення індексу прискорює процес пошуку інформації, але може дещо уповільнити процес її зміни користувачем (додавання, редагування та видалення) у режимі запуску 1С підприємства. Тому індекси слід створювати усвідомлено і лише у тому випадку, якщо точно відомий запит, для якого такий індекс необхідний. Не слід створювати індекси "про всяк випадок" або свідомо надлишкові індекси. Наприклад, ніколи не слід додатково індексувати перший вимір регістру, оскільки для пошуку за значенням першого виміру підходить основний індекс таблиці підсумків, який автоматично створить платформа.

У конфігурації описано регістр накопичення ТовариНа Складах:

Рис 1. Приклад структури регістру накопичення товарів на складах

Платформа 1С:Підприємство автоматично створить для таблиці залишків даного регістру індекс за періодом і всіма вимірами в тому порядку, в якому вони перераховані в конфігураторі.

Розглянемо кілька прикладів запитів та проаналізуємо, чи зможуть вони оптимально виконуватись за такої структури даних.

Запит 1

У разі порушення вимога 2. У разі відсутня відбір за першим полю індексу (Склад). Такий запит не зможе виконатись оптимально. Для виконання серверу СУБД доведеться перебирати (сканувати) всі записи таблиці. Час виконання цієї операції безпосередньо залежить від кількості записів у таблиці залишків регістру і може бути дуже великим (і збільшуватиметься зі зростанням кількості даних).

Варіанти оптимізації:

• Проіндексувати вимір «Номенклатура»
• Поставити вимір «Номенклатура» першим у списку вимірів. Будьте уважні під час використання цього методу. У конфігурації можуть бути інші запити, які можуть сповільнитися внаслідок цієї перестановки.

Запит 2

У цьому випадку порушено вимогу 3. Між вимірами «Склад» та «Якість» у структурі регістру знаходиться вимір «Номенклатура», який не вказано за умови запиту. Цей запит також не зможе виконуватися оптимально. При його виконанні СУБД виконає пошук першого поля індексу, але потім вимушено просканує деяку його частину. Сканування призведе до збільшення часу виконання запиту та блокування надлишкових записів у таблиці, тобто до зниження загальної пропускної спроможності системи.

Варіанти оптимізації:

• Додати до запиту умову для вимірювання «Номенклатура»
• Прибрати з запиту умову вимірювання «Якість»
• Перенести «Номенклатуру» з вимірів до реквізитів
• Поміняти місцями виміри «Номенклатура» та «Якість

Запит 3

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

4. Використання логічного АБО в умовах

4.1 Використання логічного АБО у секції ДЕ запиту

Не слід використовувати АБО у секції ДЕ запиту. Це може призвести до того, що СУБД не зможе використовувати індекси таблиць та виконуватиме сканування, що збільшить час роботи запиту та ймовірність виникнення блокувань. Натомість слід розбити один запит на кілька і об'єднати результати.

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

ВИБРАТИ Товар . Найменування ЗДовідник . Товари ЯК Товар ДЕ Артикул = "001" АБОАртикул = "002"

слід замінити на запит

ВИБРАТИ Товар . Найменування ЗДовідник . Товари ЯК Товар ДЕ Артикул = "001" |ОБ'ЄДНАТИ ВСЕ |ВИБРАТИ Товар . Найменування ЗДовідник . Товари ЯК Товар ДЕ Артикул = "002"

4.2. Увімкнення користувачів у кілька ролей, кожна з яких має RLS

1 З RLS (Record Level Security) або обмеження прав на рівні запису - це налаштування прав користувачів у системі 1 З, яка дозволяє розділити права для користувачів у розрізі даних, що динамічно змінюються.

Якщо в конфігурації описано кілька ролей з умовами RLS, то не слід призначати одному користувачеві більше однієї ролі. Якщо один користувач буде включений, наприклад, у дві ролі з RLS - бухгалтер і кадровик, то при виконанні всіх його запитів до умов будуть додаватися умови обох RLS з використанням логічного АБО. Таким чином, навіть якщо у вихідному запиті немає умови АБО, воно з'явиться там після додавання умов RLS. Такий запит може виконуватися неоптимально – повільно і з надмірними блокуваннями.

Натомість слід створити "змішану" роль - "бухгалтер-кадровик" і прописати її RLS таким чином, щоб уникнути використання АБО в умові, а користувача включити в цю одну роль.

4. 3 Використання АБО в умовах з'єднання

Не рекомендується використовувати логічне АБО в умовах з'єднання, тобто в секції запиту. Це також може призвести до вибору неоптимального плану та повільної роботи запиту. Простого універсального способу переписати такий запит без використання АБО не існує. Слід проаналізувати вирішуване завдання та спробувати знайти інший алгоритм її розв'язання.

5.Використання підзапитів за умови з'єднання

Не слід використовувати підзапити за умови з'єднання. Це може призвести до значного уповільнення запиту та (в окремих випадках) до повної непрацездатності на деяких СУБД. Приклад запиту з використанням підзапиту за умови з'єднання:

Запит . Текст = "ВИБРАТИ |З | Ціни.Період В ( | ВИБРАТИ МАКСИМУМ (Ціни Минулого Місяця. Період) | З РеєстрВідомостей.Ціна ЯК ЦіниМинулогоМісяця | ДЕ Ціни Минулого Місяця. Період< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | І ЦіниМинулогоМісяця.Номенклатура = ЗалишкиТоварів.Номенклатура |) | ДЕ Залишки Товарів.Склад = &Склад";

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

Запит . Текст = " // Максимальні дати встановлення цін у минулому періоді для даних номенклатур | ВИБРАТИ | ЗалишкиТоварів.Номенклатура ЯК Номенклатура, | МАКСИМУМ(Ціни.Період) ЯК Період |ПОМІСТИТИ ДатиПоНоменклатурам | |З | РегістрНакопичення.ТовариНаСкладах.Залишки(...) ЯК ЗалишкиТоварів | ЛІВОЕ З'ЄДНАННЯ РеєстрВідомостей.Ціна ЯК Ціни | ПО Ціни.Номенклатура = ЗалишкиТоварів.Номенклатура І | Ціни.Період< НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | ЗГРУПУВАТИ ЗА ЗАЛИШКАМИ Товарів.Номенклатура | ДЕ Залишки Товарів.Склад = &Склад; // Вибрати дані щодо ціни за знайдений період | ВИБРАТИ | Номенклатура ЯК Номенклатура, | Ціни.Ціна ЯК ЦінаМинулогоМісяця |З дати за номенклатурами | | ЛІВОЕ З'ЄДНАННЯ РеєстрВідомостей.Ціна ЯК Ціни | ПО Ціни.Номенклатура = ЗалишкиТоварів.Номенклатура І | Ціни.Період = ДатиПо Номенклатурам.Період " ;

6. Отримання даних через точку від полів складового типу

Якщо в запиті використовується отримання значення через точку від поля складеного посилання типу, то при виконанні цього запиту буде з'єднуватися з усіма таблицями об'єктів, що входять в цей складовий тип. В результаті SQL текст запиту надзвичайно ускладнюється, і за його виконання оптимізатор СУБД може вибрати неоптимальний план. Це може призвести до серйозних проблем продуктивності і навіть непрацездатності запиту в окремих випадках.

Зокрема, не рекомендується звертатися до реквізитів реєстратора регістру (наприклад, “ТовариНа Складах.Реєстратор.Дата”) тощо. При цьому не важливо в якій частині запиту ви використовуєте реквізит, отриманий через точку від поля складового типу - у списку полів, що повертаються, в умові і т.п. У всіх випадках таке звернення може спричинити проблеми продуктивності.

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

приклад

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

Запит . Текст = "ВИБРАТИ | Продаж.Реєстратор.Номер, | Продажі.Реєстратор.Дата, | Продажі.Контрагент, | Продажі. | Продажі. |З |ДЕ...

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

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

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

7. Фільтрування віртуальних таблиць без використання параметрів

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

Наприклад, наступний запит використовує секцію Де запиту для вибірки з віртуальної таблиці.

Запит . Текст = "ВИБРАТИ | Номенклатура |З | РеєстрНакопичення.ТовариНаСкладах.Залишки() |ДЕ | Склад = &Склад";

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

Запит . Текст = "ВИБРАТИ | Номенклатура |З | РеєстрНакопичення.ТовариНаСкладах.Залишки(, Склад = &Склад)";

За нормами статті 134 Трудового кодексу РФ роботодавці повинні забезпечити працівникам підвищення рівня заробітної плати у зв'язку із зростанням споживчих цін на товари та послуги. Порядок індексації (з урахуванням думки профспілки) прописується у колективному договорі чи локальному нормативному акті організації. У статті експерти 1С розповідають, як у «1С:Зарплаті та управлінні персоналом 8» редакції 3 провести індексацію штатного розкладу та чинних тарифів тарифних ставок співробітників (з подальшим перерахунком середнього заробітку).

Під індексацією в «1С:Зарплаті та управлінні персоналом 8» (ред. 3) зазвичай розуміють два завдання:

• індексація штатного розкладу - акордна зміна тарифних ставок у штатному розкладі (якщо у програмі він використовується);
• індексація чинних тарифів тарифних ставок працівників - збільшення тарифних ставок з подальшим перерахунком середнього заробітку.

Індексація штатного розкладу можлива, якщо у програмі «1С:Зарплата та управління персоналом 8» редакції 3 ведеться штатний розклад із збереженням історії (встановлені прапори Ведеться штатний розклад та Ведеться історія змін штатного розкладу в меню Налаштування - Кадровий облік - Налаштування штатного розкладу).

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

Мал. 1. Індексація штатного розкладу яких зазначено тарифні групи та розряди (категорії), необхідно спочатку провести Затвердження тарифної групи (меню Зарплата – Затвердження тарифної групи).

Для відображення зміни розмірів тарифних ставок для тарифних розрядів у штатному розкладі у документі Затвердження тарифної групи слід натиснути на кнопку Змінити штатний розклад. При цьому документ Зміна штатного розкладу створюється автоматично. Індексація штатного розкладу у програмі не тягне за собою автоматичної індексації заробітку співробітників і не впливає на розрахунок середнього заробітку.

Індексація чинних тарифів тарифних ставок співробітників

Починаючи з версії 3.1.3 у програмі «1С:Зарплаті та управлінні персоналом 8» редакції 3 індексація діючих тарифів тарифних ставок співробітників виражається не просто у збільшенні тарифної ставки, а може поєднуватись із змінами та інших нарахувань, що визначають склад сукупної тарифної ставки. При цьому коефіцієнт індексації не визначається, а розраховується як відношення нової сукупної тарифної ставки до колишньої. Індексація чинних тарифів тарифних ставок працівників здійснюється документом Зміна планових нарахувань (меню Зарплата – Зміна оплати працівників – кнопка Створити).

Щоб підвищення тарифних ставок сприймалося системою як індексація, т. е. вказувався підвищуючий коефіцієнт розрахунку середнього заробітку, у документі Зміна планових нарахувань слід встановити прапор Враховувати як індексацію заробітку (рис. 2).

Цей прапор доступний у документі, якщо включено можливість використання механізмів індексації заробітної плати прапором Виконується індексація заробітку працівників (меню Налаштування - Розрахунок зарплати). Використовуючи кнопки Підбір або Заповнити, потрібно сформувати перелік співробітників, заробіток яких підлягає індексації. Далі, за кнопкою Заповнити показники в документі Зміна оплати співробітників відкривається вікно, де можна ввести фіксовані значення (Фікс. значення - див. малюнок 2), або перерахувати попередньо заповнені за допомогою математичних операцій (Додати, Помножити на), вказавши, наприклад, коефіцієнт, який слід помножити Оклад, Годинний тариф чи інший показник, що визначають склад сукупної тарифної ставки. На кнопці Наказ про індексацію заробітку формується друкована форма наказу про індексацію заробітку працівників.

Якщо на підприємстві використовуються тарифні групи, то документ Зміна планових нарахувань можна сформувати за кнопкою Змінити планові нарахування у документі Затвердження тарифної групи (меню Зарплата - Затвердження тарифної групи).