Павло чисту 1
Іноді, може скластися так, що на вже довгий час працює базі потрібно змінити типу реквізиту, або додати індексовані поля, або просто додати реквізит. Так ось після цього, нас чекає довгий процес (якщо база великих розмірів) реструктуризації таблиці. У цій статті я розгляну алгоритм значного скорочення часу реструктуризації.
Отже. Програмісти 80lvl швидше за все знають все і навіть більше, ніж описано в статті, тому ця публікація буде орієнтована в першу чергу на новачків. А так як у новачка швидше за все ні репутації і стартмані - всі скрипти я не буду прикріплювати, а викладу в статті.
Поїхали. Припустимо у вашій конфігурації є якийсь документ, з 5 табличними частинами. В СУБД (в нашому прикладі PosgreSQL, але все нижче сказане справедливо і інших СУБД) такий документ з'явиться у вигляді 6 таблиць
.png "Павло чисту 1 (прискорення реструктуризації таблиць)")
Продовжуємо, додаємо реквізит в табличну частину в конфігураторі, у мене це число довжиною 10, точність 0 (під час всіх маніпуляцій його можна не закривати), зберігаємо, але не оновлюємо. Перейменовуємо все таблиці документа в pgAdmin або чим ви там користуєтеся (у мене це пара pgAdmin і EMS SQL Manager PostgreSQL), наприклад _document39 в _document39_src
І створюємо копії наших перейменованих таблиць (порожні) з початковими іменами, в нашому прикладі робимо порожню копію _document39_src з ім'ям _document39.
Якщо подивитися в підприємстві, у нас немає жодного документа.
Тепер, коли 1С вважає, що у нас немає документів, в конфігураторі тиснемо оновити, реструктуризація проходити миттєво (якщо виникнуть помилки, тиснемо оновити ще раз, до тих пір, поки не з'явиться вікно про прийняття змін).
Дивимося яке ім'я отримала нова колонка таблиці, яка відповідає новому реквізиту.
У мене це _fld1097. Повертаємося до нашої вихідної таблиці, яку ми перейменували в _document39_src, додаємо нову колонку в неї
Ставимо значення за замовчуванням, тут 0 і тиснемо ОК. Весь процес зайняв близько 1 години (в 48 разів швидше). Після того як колонка створена, стираємо значення за замовчуванням і перейменовуємо таблицю назад (у нас в _document39)
Запускаємо підприємство і перевіряємо. Радіємо або плачем.
Отже, це ми додали реквізит, розглянемо тепер випадок, якщо нам треба змінити тип реквізиту, наприклад, було число (5, 2), треба число (10, 4), або додати індексів.
Тут є два варіанти.
Варіант перший. Створюємо копії таблиць і заливаємо в них дані з основної таблиці
Після цього очищаємо вихідні таблиці, тобто доходимо до моменту, коли 1С думає, що у нас немає записів в таблицях документ. Робимо всі необхідні зміни в конфігураторі і оновлюємо. Тепер нам треба повернути дані назад
Запускаємо підприємство і перевіряємо. Радіємо або плачем.
Варіант другий. Хтось вважає, що INSERT INTO працює повільно, тому можна використовувати такі скрипти, що працюють ні з копіями таблиці а з файлами на диску
де 'e: / _ document39' це файл в корені диска е.
Скрипт завантажує дані назад
На цьому, мабуть все.
Як видно, процес це все одно довгий (близько 18 годин у мене). Що ми отримали, близько 19-ї години проти 48 при зміні типу реквізиту і додаванні індексів, і близько 1 години проти 48 годин при додаванні реквізиту.
PS. У мене є підозра, що на інших СУБД реструктуризація засобами платформи буде швидше. До того ж у мене стояв старий PosgresSQL, ще 8.2.4-3.1