Как быстро добавить новый реквизит в шапку документа в 1С 7.7 без долгой реструктуризации базы?

Каждый разработчик, работающий с базами данных на платформе 1С:Предприятие 7.7, рано или поздно сталкивается с проблемой колоссального замедления при обновлении конфигурации. Добавление одного простого реквизита в шапку популярного документа на крупной работающей базе за несколько лет продаж может парализовать работу предприятия на долгие часы. Процесс реструктуризации «шерстит» терабайты данных, заставляя администраторов и программистов проводить бессонные ночи в ожидании завершения операции.

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

Почему штатное добавление реквизита в 1С 7.7 длится часами?

Для того чтобы понять, как обойти проблему, выясним причину медленной работы стандартного механизма обновления. При добавлении нового реквизита в шапку документа Конфигуратор производит ряд ресурсоемких операций:

1. Отсутствие поддержки быстрых DDL-команд: Вместо выполнения быстрой SQL-команды добавления колонки ALTER TABLE, платформа 1С 7.7 создает временную копию таблицы шапки документа (например, DH1234 копируется во временную _temp_DH1234). Затем система построчно копирует данные из старой таблицы в новую, дополняя каждую строку значением по умолчанию для нового поля, после чего удаляет старую таблицу и переименовывает временную. На терабайтных базах с миллионами документов этот процесс занимает часы и генерирует гигантский объем транзакционных логов СУБД.
2. Общие реквизиты документов: Если новый реквизит создается как «Общий реквизит документов», платформа обязана модифицировать глобальную таблицу журналов _1SJOURN. Данная таблица хранит заголовки абсолютно всех документов системы. Ее перестроение на больших базах гарантированно приводит к зависанию процесса.
3. Графы отбора и сортировка: Если для нового реквизита установлены флаги «Отбор по реквизиту» или «Сортировка», система начинает перестраивать системную таблицу индексов и связей 1SCRDOC. Платформа запускает полное сканирование базы для генерации новых записей графа отбора, что нагружает дисковую подсистему до предела.

Рассмотрим детально, как обойти эти ограничения и решить задачу быстро.

Способ 1. Ручное добавление поля и подмена словаря конфигурации (самый популярный метод)

Этот метод основан на обмане Конфигуратора. Если физическая структура таблиц в базе данных (в СУБД SQL или файлах DBF) полностью соответствует описанию метаданных в конфигурации, то при запуске Конфигуратор считает, что реструктуризация не требуется, и сохраняет изменения мгновенно. Разберем этот процесс по шагам.

Шаг 1. Создание пустой конфигурации-шаблона

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

1. Создадим резервную копию файла конфигурации 1Cv7.MD нашей рабочей базы.
2. Создадим на диске новую пустую папку и скопируем туда файл 1Cv7.MD.
3. Откроем эту пустую папку в режиме Конфигуратора (база будет пустой, без данных).
4. Найдем нужный документ, добавим в его шапку новый реквизит с необходимым типом данных (например, Строка, Число или Справочник).
5. Сохраним конфигурацию. При сохранении в этой пустой папке сформируются новые файлы метаданных: обновленный файл 1Cv7.MD, а также файл словаря базы данных — 1Cv7.DD (для файловой DBF-версии) или 1Cv7.DDS (для версии на MS SQL Server).

Шаг 2. Определение физического имени нового поля

Откроем сгенерированный файл словаря (1Cv7.DD или 1Cv7.DDS) любым текстовым редактором (например, Notepad++). Нам нужно найти описание таблицы нашего документа. Поиск можно осуществлять по идентификатору документа или по названию его таблицы шапки (например, DH1234, где 1234 — это внутренний идентификатор объекта в системе).

В тексте описания таблицы мы увидим перечень полей. Найдем новое добавленное поле. Оно будет иметь системное имя вида SP12345 (где 12345 — уникальный код реквизита). Обратим особое внимание на физический тип данных этого поля в СУБД. Например:

• Для строк: CHAR(10) или VARCHAR(20).
• Для чисел: NUMERIC(10, 2).
• Для справочников или других документов: CHAR(9) (так как ссылки в 1С 7.7 хранятся в виде 36-ричных строк длиной 9 символов).

Зафиксируем для себя точное имя поля и его тип.

Шаг 3. Модификация структуры физической таблицы в рабочей базе

Теперь нам нужно добавить это поле непосредственно в рабочую базу данных, минуя механизмы 1С. Действия различаются в зависимости от формата базы данных.

Вариант А. Для баз данных на MS SQL Server

Запустим среду управления СУБД Microsoft SQL Server Management Studio (SSMS), подключимся к нашей рабочей базе данных и откроем окно создания нового SQL-запроса. Нам необходимо выполнить транзакционный запрос добавления новой колонки. Проанализируем пример такого запроса:

ALTER TABLE DH1234 ADD SP12345 CHAR(9) NOT NULL DEFAULT ' 0 '

В данном примере мы добавляем колонку типа справочника (длина 9 символов). Обратите внимание на значение по умолчанию DEFAULT ' 0 '. В СУБД для пустых значений ссылок в 1С 7.7 используется именно такое представление. Если реквизит числовой, запрос будет выглядеть следующим образом:

ALTER TABLE DH1234 ADD SP12345 NUMERIC(10, 2) NOT NULL DEFAULT 0

Данная операция выполняется на уровне MS SQL Server практически мгновенно (в течение нескольких секунд), так как современные СУБД умеют быстро добавлять столбцы со значениями по умолчанию без перезаписи всей таблицы.

Вариант Б. Для файловых баз (DBF)

Для файловых версий нам понадобится любой DBF-редактор, который умеет корректно изменять структуру таблиц без повреждения данных (например, DBF Commander, DBEd, FoxPro или плагины для Total Commander).

1. Найдем в каталоге рабочей базы файл таблицы шапки нашего документа (например, DH1234.DBF). Перед началом работы обязательно сделаем его резервную копию!
2. Откроем этот файл в DBF-редакторе.
3. Перейдем в режим изменения структуры таблицы и добавим новое поле. Имя поля (например, SP12345), тип данных и длину укажем в строгом соответствии с тем, что мы увидели в файле словаря 1Cv7.DD.
4. Сохраним изменения в файле.

Шаг 4. Финальная подмена файлов

Теперь физическая структура базы данных полностью соответствует новой конфигурации. Осталось завершить интеграцию изменений:

1. Скопируем обновленный файл конфигурации 1Cv7.MD и новый файл словаря 1Cv7.DD (или 1Cv7.DDS) из нашей тестовой пустой папки, подготовленной на Шаге 1.
2. Вставим эти файлы с заменой в каталог рабочей базы данных.
3. Для DBF-версии: Обязательно удалим все индексные файлы (файлы с расширением *.CDX) в каталоге рабочей базы. После этого запустим 1С в режиме Конфигуратора и выполним процедуру полного переиндексирования таблиц.
4. Запустим базу в режиме «Предприятие». Платформа успешно считает конфигурацию, не запуская долгий процесс реструктуризации метаданных, так как физическая таблица уже содержит нужное поле.

Способ 2. Особенности применения метода в распределенных базах (УРИБ/РИБ)

Если на предприятии развернута распределенная информационная база (УРИБ), применение ручной подмены файлов имеет свои нюансы. Многие администраторы опасаются применять этот метод из-за риска рассинхронизации периферийных узлов. Выясним, как сделать это безопасно.

Рассмотрим алгоритм применения метода для распределенных систем:

1. На центральном узле распределенной базы выполняем все действия по ручному добавлению поля (Способ 1). База успешно запускается в центре.
2. При выгрузке пакетов автообмена для периферийных узлов конфигурация передается в измененном виде. Однако физически таблицы на подчиненных узлах еще не содержат новой колонки.
3. Для предотвращения падения баз на периферийных узлах при загрузке изменений нам необходимо предварительно выполнить на них ту же самую операцию модификации структуры БД.
4. Если периферийный узел на SQL: Перед загрузкой файла переноса данных запускаем SQL-скрипт ALTER TABLE ... ADD ... непосредственно на сервере периферийного узла.
5. Если периферийный узел на DBF: Вносим изменения структуры в файл DH*.DBF на удаленной точке через DBF-редактор и удаляем индексные файлы.
6. Выполняем штатный прием пакета обмена. Конфигурация обновляется без долгой и мучительной реструктуризации на местах.

Способ 3. Псевдореквизиты (альтернативные архитектурные решения без изменения таблиц)

Бывают ситуации, когда изменять физическую структуру таблиц документов категорически не рекомендуется (например, из-за жестких регламентов обновления, высокой вероятности конфликтов блокировок или в случае, когда база работает в режиме 24/7 и технологическое окно для обслуживания отсутствует).

В таких случаях мы можем отказаться от добавления физического реквизита в шапку документа и применить альтернативные методы хранения информации.

Вариант А. Механизм свойств и подчиненных справочников

Вместо изменения структуры документа мы создаем подчиненный справочник, который будет хранить значения дополнительных свойств документов.

Рассмотрим этот подход подробнее:

• Создадим справочник (например, ЗначенияСвойствДокументов), подчиненный нашему документу. Справочник будет иметь реквизит Значение с необходимым типом данных.
• На форму документа выведем текстовое поле или поле ввода. При открытии формы документа будем считывать значение из подчиненного справочника, а при записи документа — записывать его обратно в справочник.

Посмотрим на пример кода чтения и записи такого псевдореквизита:

// При открытии формы документа
Процедура ПриОткрытии()
    Спр = СоздатьОбъект("Справочник.ЗначенияСвойствДокументов");
    Спр.ИспользоватьВладельца(ТекущийДокумент());
    Если Спр.НайтиПоРеквизиту("Свойство", ИмяНужногоСвойства, 1) = 1 Тогда
        ЗначениеРеквизитаНаФорме = Спр.Значение;
    Иначе
        ЗначениеРеквизитаНаФорме = "";
    КонецЕсли;
КонецПроцедуры

// При записи документа
Процедура ПриЗаписи()
    Спр = СоздатьОбъект("Справочник.ЗначенияСвойствДокументов");
    Спр.ИспользоватьВладельца(ТекущийДокумент());
    Если Спр.НайтиПоРеквизиту("Свойство", ИмяНужногоСвойства, 1) = 0 Тогда
        Спр.Новый();
        Спр.Владелец = ТекущийДокумент();
        Спр.Свойство = ИмяНужногоСвойства;
    КонецЕсли;
    Спр.Значение = ЗначениеРеквизитаНаФорме;
    Спр.Записать();
КонецПроцедуры

Этот метод полностью исключает необходимость реструктуризации таблиц документов. Добавление новых псевдореквизитов происходит мгновенно в режиме «1С:Предприятие».

Вариант Б. Использование внешних таблиц и компоненты 1С++

Если ваша база данных работает под управлением MS SQL Server и в конфигурации используется внешняя компонента 1С++, мы можем спроектировать собственную независимую таблицу в СУБД для хранения любых дополнительных реквизитов документов.

Проанализируем преимущества этого подхода:

• Платформа 1С ничего «не знает» о существовании этой внешней таблицы. Файл конфигурации 1Cv7.MD никак не изменяется.
• Мы можем создавать любые индексы и связи на стороне SQL без ограничений платформы.
• Чтение и запись осуществляются моментально через прямые SQL-запросы к созданной нами внешней таблице с привязкой по уникальному идентификатору документа IDDOC.

Используя предложенные методы, вы сможете оптимизировать процесс администрирования баз данных 1С:Предприятие 7.7 и сберечь драгоценное время пользователей и разработчиков.