При работе с высоконагруженными или исторически сложившимися базами на платформе 1С 7.7 программисты часто сталкиваются с ситуацией, когда добавление даже одного нового реквизита в справочник превращается в многочасовое ожидание. В некоторых случаях процесс реструктуризации может длиться более 12 часов даже на современных SSD-накопителях. Разберем, почему это происходит, какие технические ограничения существуют у формата DBF и как решить проблему «православными» и архитектурными методами.
Проанализируем ситуацию: когда вы добавляете реквизит в конфигураторе, система выполняет полную реструктуризацию таблицы справочника. Если база файловая (DBF), 1С создает временную таблицу, копирует туда данные из старой, удаляет старую и переименовывает новую. Однако основная нагрузка зачастую ложится не на саму таблицу справочника, а на вспомогательные механизмы:
1SCONST.DBF. Все периодические значения всех объектов базы хранятся именно в этом файле. Если его размер превышает 500 Мб или количество записей приближается к критическому порогу, любая проверка индексов занимает колоссальное время..CDX. При большом количестве элементов (сотни тысяч и миллионы) это требует огромных ресурсов CPU и диска.Если штатное сохранение через Конфигуратор не помогает, рассмотрим альтернативный путь — ручную правку структуры таблиц. Этот метод позволяет добавить реквизит за считанные минуты, минуя тяжелые процедуры реструктуризации 1С.
Порядок действий:
1CV7.DD (или .DDS для SQL). Ищем наш справочник и находим имя поля, например SP12345.SC100.DBF) в рабочей базе.SP12345), тип и длину в точном соответствии с тем, что мы видели в словаре «пустышки».1Cv7.MD и словарь 1Cv7.DD в рабочей базе на файлы из нашей подготовленной «пустышки».*.CDX) в каталоге базы.Наличие 100 и более реквизитов в одном справочнике — это явный признак нарушения принципов проектирования баз данных. Рассмотрим, как можно реорганизовать структуру, чтобы повысить стабильность системы:
Использование подчиненных справочников (Extra Properties)
Вместо того чтобы плодить колонки в основной таблице, создадим подчиненный справочник «ДополнительныеРеквизиты». В нем будет всего два поля: ВидСвойства (ссылка на перечисление или другой справочник) и Значение (строка или неопределенный тип). Это позволит хранить неограниченное количество свойств для каждого товара без изменения структуры БД.
Отказ от избыточной периодичности
Проанализируем, действительно ли все 100 реквизитов должны быть периодическими. В 1С 7.7 файл 1SCONST.DBF имеет ограничение в 16,7 млн записей. При достижении этого предела база может просто перестать открываться. Если вам нужны только актуальные цены или скидки, храните их в обычных реквизитах или в отдельных регистрах (если конфигурация позволяет).
Если файловый вариант (DBF) перестал справляться с объемами, наиболее логичным решением будет переход на SQL Server. В SQL-версии 1С 7.7 многие ограничения снимаются, однако появляются новые нюансы:
SELECT *) может упасть.Рассмотрим пример того, как программно можно обращаться к данным, если мы решили вынести часть реквизитов в подчиненную структуру, чтобы не перегружать основной справочник:
// Пример получения значения дополнительного свойства
Функция ГетДопСвойство(ТекТовар, ИмяСвойства)
СпрДоп = СоздатьОбъект("Справочник.ДопРеквизиты");
СпрДоп.ИспользоватьВладельца(ТекТовар);
СпрДоп.ВыбратьЭлементы();
Пока СпрДоп.ПолучитьЭлемент() = 1 Цикл
Если СпрДоп.ВидСвойства.Наименование = ИмяСвойства Тогда
Возврат СпрДоп.Значение;
КонецЕсли;
КонецЦикла;
Возврат "";
КонецФункции
Подведем итог: если ваша база 1С 7.7 тормозит при сохранении из-за количества реквизитов, первым делом попробуйте «православный метод» с ручной правкой DBF. Однако в долгосрочной перспективе единственным верным решением будет нормализация структуры данных или миграция на SQL, так как формат DBF имеет физические пределы, преодолеть которые программно невозможно.