В процессе разработки и сопровождения конфигураций на платформе 1С:Предприятие часто возникает задача расширения стандартного функционала. Одной из типичных проблем является ограничение длины строковых дополнительных реквизитов и сведений. Например, пользователям может потребоваться хранить длинные описания, ссылки на внешние ресурсы, технические спецификации или интеграционные маркеры объемом до 1000 символов и более в стандартных свойствах объектов.
В этой статье мы подробно разберем, как устроен механизм свойств на уровне платформы, как правильно увеличить длину строкового свойства через Конфигуратор, проанализируем неочевидные риски этого процесса для производительности базы данных и рассмотрим наиболее архитектурно верное решение этой задачи.
Прежде чем переходить к изменениям в конфигурации, проанализируем, как механизм свойств реализован на уровне платформы 1С. В типовых и самописных решениях для этого используется связка из нескольких объектов метаданных:
СвойстваОбъектов или ДополнительныеРеквизитыИСведения. Этот объект определяет, какие именно свойства (характеристики) могут быть созданы в системе, и задает их типы данных (строка, число, дата, ссылка на справочник и т.д.).ЗначенияСвойствОбъектов. В нем физически хранятся записи в разрезе объектов (номенклатура, контрагенты, документы) и самих свойств.ЗначенияСвойствОбъектов) для хранения предопределенных текстовых значений, выбираемых пользователем из списка.Главный нюанс кроется в типе ресурса Значение в регистре сведений. Он имеет составной тип данных, который формируется динамически и называется Характеристика.СвойстваОбъектов. Платформа 1С автоматически включает в этот тип все типы данных, которые разрешены в свойстве "Тип значения характеристик" соответствующего Плана видов характеристик. Поэтому прямое изменение регистра сведений невозможно — его тип данных жестко завязан на ПВХ.
Если нам необходимо пойти самым простым путем и увеличить длину строки непосредственно в механизме характеристик, выполним следующие шаги:
СвойстваОбъектов или ДополнительныеРеквизитыИСведения).Строка.После выполнения этих действий платформа автоматически пересчитает тип Характеристика.СвойстваОбъектов во всех связанных таблицах, включая регистр сведений, и пользователи смогут вводить длинные строки.
Хотя описанный выше способ кажется простым и быстрым, в реальных высоконагруженных системах он может привести к серьезным техническим проблемам. Выясним причину, почему разработчики избегают прямого увеличения длины строк в ПВХ:
Значение в регистре сведений ЗначенияСвойствОбъектов часто является индексируемым. СУБД (например, MS SQL Server, PostgreSQL) накладывают жесткие ограничения на максимальный размер индексного ключа (например, 900 байт для MS SQL Server). Если размер индексируемого строкового поля превышает этот лимит, запись в базу данных начнет завершаться критическими ошибками СУБД.0 (неограниченная длина), СУБД будет хранить такие данные во внешних таблицах (типы данных NVARCHAR(MAX) или NTEXT). Подобные поля категорически запрещено использовать в условиях соединений запросов, группировках или сортировках. Это приведет к тому, что вы не сможете построить отчеты с группировкой по данному свойству или быстро отобрать данные в СКД.Чтобы обойти технические ограничения СУБД и сохранить высокую производительность системы при работе со строками длиной до 1000 символов и более, применим лучшую практику разработки 1С. Создадим выделенный справочник для хранения длинных текстов.
Разберем этот процесс по шагам:
ДополнительныеТекстовыеЗначения.ЗначениеТекстом, установим для него тип данных Строка (неограниченной длины) и включим свойство Многострочный режим.СвойстваОбъектов), откроем его свойство Тип значения характеристик и добавим флаг напротив нашего нового справочника СправочникСсылка.ДополнительныеТекстовыеЗначения.Теперь в режиме "1С:Предприятие" при создании нового свойства пользователь сможет выбрать в качестве типа значения созданный нами справочник ДополнительныеТекстовыеЗначения. Сам длинный текст будет храниться в реквизите справочника, а в регистре сведений будет находиться лишь компактная ссылка на элемент справочника (16 байт), что никак не повлияет на производительность индексов СУБД.
Посмотрим на пример запроса, с помощью которого мы можем безопасно извлечь наши длинные текстовые данные без потери производительности при соединении таблиц:
ВЫБРАТЬ
ЗначенияСвойств.Объект КАК Объект,
ЗначенияСвойств.Свойство КАК Свойство,
ВЫРАЗИТЬ(ЗначенияСвойств.Значение КАК Справочник.ДополнительныеТекстовыеЗначения).ЗначениеТекстом КАК ДлинныйТекст
ИЗ
РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойств
ГДЕ
ЗначенияСвойств.Свойство = &ЦелевоеСвойство
Используя конструкцию ВЫРАЗИТЬ, мы явно приводим составной тип характеристики к нашему новому справочнику и получаем доступ к его реквизиту неограниченной длины. Это гарантирует корректное выполнение запроса на уровне СУБД.
Если вы работаете с типовой конфигурацией (например, 1С:ERP, 1С:Комплексная автоматизация или 1С:Управление торговлей), которая находится на поддержке, прямое изменение ПВХ усложнит процедуру последующих обновлений.
В современных реалиях платформы 1С рекомендуется использовать Расширения конфигурации. Рассмотрим особенности этого подхода:
ДополнительныеТекстовыеЗначения непосредственно внутри расширения.Важное предупреждение: В некоторых старых версиях платформы 1С 8.3 изменение типов ПВХ через расширения могло вызывать проблемы с реструктуризацией данных. Убедитесь, что вы используете актуальную версию платформы, и обязательно выполните резервное копирование информационной базы перед применением изменений в рабочей среде.
Проанализировав все варианты, мы видим, что создание отдельного справочника для длинных строк является наиболее безопасным, гибким и производительным решением, которое убережет вашу систему от падения производительности и ошибок СУБД.