Как лучше добавить дополнительное текстовое поле в большой справочник в 1С 7.7?

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

Вариант 1: Добавление нового реквизита в справочник

Это самый очевидный и простой в реализации способ. Мы заходим в конфигуратор, открываем справочник Товары и добавляем новый реквизит с типом Строка и установленным флагом Неограниченная длина. Рассмотрим подробнее, как это работает «под капотом» платформы.

Технические особенности хранения:

1. В файловой версии (DBF) данные строк неограниченной длины не хранятся в основной таблице справочника. В файле справочника (например, SC123.DBF) создается поле длиной всего 10 символов, которое является ссылкой на блок в общем файле 1SBlob.dbf.
2. В версии SQL такие данные хранятся в полях типа IMAGE или TEXT.

Плюсы этого решения:

• Простота обращения в коде: ТекТовар.НовыйРеквизит.
• Не нужно создавать дополнительные объекты метаданных и настраивать связи.
• Для файловой базы добавление такого реквизита практически не увеличивает размер основной таблицы справочника, так как физически данные выносятся в 1sblob.dbf.

Минусы и риски:

• Замедление работы: При каждом обращении к объекту справочника (например, в циклах перебора или при использовании стандартных запросов) платформа считывает объект целиком. Если в справочнике много «тяжелых» полей, это может привести к избыточному чтению данных, даже если вам нужно только Наименование.
• Реструктуризация: На очень больших справочниках (сотни тысяч записей) добавление реквизита в конфигураторе может занять значительное время, так как 1С будет пересоздавать таблицу и индексы.
• Фрагментация 1SBlob: Если поле будет часто редактироваться, общий файл длинных строк может начать бесконтрольно расти, что со временем потребует процедуры упаковки (Pack).

Вариант 2: Использование подчиненного справочника

Если поле заполняется крайне редко (1 на 100 записей), логично вынести его в отдельную таблицу. Мы можем создать новый справочник, например, ДопХарактеристики, и сделать его подчиненным справочнику Товары. Проанализируем этот подход.

Плюсы решения:

• Чистота данных: В основной таблице справочника товаров не появляется лишних колонок.
• Производительность: При обычном переборе товаров или формировании стандартных отчетов лишние данные не подкачиваются из базы. Мы обращаемся к подчиненному справочнику только тогда, когда нам действительно нужно прочитать эту характеристику.
• Масштабируемость: Если в будущем заказчик захочет добавить еще 10 подобных характеристик, нам не придется снова менять структуру основной таблицы товаров.

Нюансы реализации:

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

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

Вариант 3: Механизм свойств (по аналогии с ТиС 9.2)

Рассмотрим наиболее гибкий, но и наиболее сложный в реализации подход — создание универсального механизма дополнительных свойств. Этот метод реализован во многих типовых конфигурациях (например, «Торговля и Склад»). Суть заключается в создании системы из нескольких справочников: ВидыСвойств, ЗначенияСвойств и связующего звена (обычно справочник, подчиненный номенклатуре, или регистр в 8-ке).

Почему стоит выбрать этот вариант:

• Пользователи могут добавлять новые виды характеристик («Цвет», «Размер», «Инструкция») в режиме 1С:Предприятие без привлечения программиста.
• Данные хранятся максимально компактно.

Сложности:

• Трудно использовать в сложных отчетах без применения прямых SQL-запросов или 1С++, так как стандартный Запрос 1С 7.7 плохо справляется с соединением большого количества таблиц свойств.

Сравнение производительности: DBF против SQL

При выборе решения важно учитывать тип используемой СУБД. Выясним причину, почему для SQL-версии добавление реквизита может быть более критичным, чем для DBF.

В файловой версии 7.7 Черный запрос (встроенный язык запросов 1С) работает по принципу перебора. В SQL-версии 7.7 «Черный запрос» часто работает неоптимально: он может выкачивать все поля таблицы, включая тяжелые IMAGE-поля, даже если они не используются в тексте запроса. Это приводит к резкому росту сетевого трафика и нагрузки на сервер.

Если вы используете **прямые запросы** (через внешние компоненты типа 1С++), то разницы практически нет: вы просто не будете включать это поле в SELECT, и оно не будет влиять на скорость получения данных. В этом случае добавление реквизита в основную таблицу выглядит более предпочтительным из-за простоты поддержки кода.

Рекомендации по выбору решения

Проанализируем ситуацию и подведем итоги. Выбор зависит от ваших долгосрочных планов:

1. Если вы хотите быстрого результата и не планируете в ближайшее время переходить на механизмы свойств, добавьте реквизит Строка неограниченной длины. Для 50 000 записей это не создаст проблем с производительностью, если вы не будете злоупотреблять выборками объектов целиком в тяжелых циклах.
2. Если база активно растет и вы опасаетесь за стабильность файла 1sblob.dbf или планируете расширять список характеристик — используйте подчиненный справочник. Это обеспечит «чистоту» основной таблицы и независимость данных.
3. Если требуется универсальность и вы готовы потратить время на написание интерфейсных функций и оптимизацию отчетов — реализуйте механизм свойств. Это наиболее профессиональный подход для крупных систем.

Важный совет: Если вы все же решили добавлять реквизит в справочник с миллионами записей в формате DBF и опасаетесь долгой реструктуризации, можно воспользоваться методикой прямой правки файлов метаданных (.dd) и структуры DBF-файла сторонними утилитами, чтобы избежать полной перезаписи таблицы платформой. Однако этот метод требует высокой квалификации и обязательного создания резервной копии.