При работе с объектом метаданных План видов характеристик (ПВХ) разработчики часто сталкиваются с ситуацией, когда платформа не позволяет установить нужную длину для числового или строкового типа данных в предопределенных элементах. Система выдает ошибку "Введены некорректные данные", даже если в конфигураторе визуально выбран нужный тип. В этой статье мы подробно разберем, как обойти это ограничение, выясним физические причины такого поведения платформы и проанализируем, почему использование примитивных типов в ПВХ считается "плохим тоном" с точки зрения производительности.
Рассмотрим стандартную ситуацию: вы создаете новый элемент в разделе Предопределенные Плана видов характеристик. Выбираете тип Число, пытаетесь установить длину 7, но платформа сбрасывает значение или выдает ошибку, позволяя оставить длину не более 2. Проанализируем, почему это происходит.
В архитектуре 1С существует жесткая иерархия наследования ограничений типов. Основным "фильтром" выступает свойство самого объекта ПланВидовХарактеристик — Тип значения характеристик. Все, что мы настраиваем внутри конкретных элементов (предопределенных или создаваемых в режиме предприятия), является лишь подмножеством того типа, который определен в корне объекта.
Пошаговое решение проблемы:
ПланВидовХарактеристик в конфигураторе.Тип значения характеристик и нажмем на кнопку выбора (три точки).Число.Длина: 2, то это и есть глобальный лимит для всего ПВХ.Выяснив, как решить техническую заминку, разберем более глубокий вопрос: почему 1С рекомендует использовать в ПВХ преимущественно ссылочные типы данных (справочники, документы) и избегать примитивных (число, строка, дата, булево)?
Проанализируем структуру таблиц на уровне СУБД (например, MS SQL Server). В 1С поле составного типа, которое включает только ссылки, хранится максимально компактно. Для него выделяется фиксированное количество полей (обычно три: идентификатор типа, номер таблицы и сам GUID записи). Сколько бы новых ссылочных типов (справочников) вы ни добавляли в ПВХ, количество колонок в физической таблице базы данных не увеличится.
Однако ситуация кардинально меняется при добавлении примитивных типов:
Число платформа создает в таблице отдельное физическое поле (например, типа NUMERIC).Строка создается свое поле (NVARCHAR).Дата — еще одно поле (DATETIME).Если ваш План видов характеристик используется в качестве Видов субконто в Регистре бухгалтерии, это приводит к "раздуванию" таблиц итогов. Каждое такое примитивное поле дублируется в таблицах движений и итогов, увеличивая объем базы данных и снижая скорость выполнения запросов.
Рассмотрим наиболее опасный сценарий использования примитивных типов в ПВХ, который служит основой для аналитики (субконто) на счетах бухгалтерского учета. Система 1С автоматически строит индексы по таблицам итогов для ускорения формирования отчетов, таких как Оборотно-сальдовая ведомость.
В большинстве современных СУБД (включая MS SQL Server) существует ограничение: в один индекс может входить не более 16 полей. В Регистре бухгалтерии значительная часть этих "слотов" уже занята системными измерениями: Период, Счет, Организация, Валюта и так далее. Каждое добавленное в ПВХ примитивное поле (число, строка) претендует на место в этом индексе. Если в ПВХ включено много примитивных типов, платформа может столкнуться с невозможностью построить эффективный индекс, что приведет к катастрофическому падению производительности при расчете остатков и оборотов.
Стоит ли паниковать, если вы видите числовые типы в типовых конфигурациях? Рассмотрим пример ПВХ НастройкиПользователя в "Бухгалтерии предприятия". Там активно используются и строки, и числа. Это допустимо, так как данный ПВХ используется для хранения настроек в РегистреСведений, а не для ведения учета в РегистреБухгалтерии. В регистрах сведений без итогов нагрузка на систему от лишних полей значительно ниже.
Если же вам необходимо хранить числовые значения именно в аналитике (субконто), мы рекомендуем использовать методику "Справочника-обертки". Рассмотрим, как это реализовать программно.
Вместо того чтобы включать тип Число напрямую в ПВХ, создадим справочник ДополнительныеЗначения. В ПВХ добавим ссылку на этот справочник. Теперь мы можем хранить числовые значения в реквизите справочника или даже в его наименовании. Посмотрим на пример кода для работы с такой характеристикой:
// Пример получения числового значения из справочника-обертки
ЗначениеХарактеристики = Выборка.Значение; // Это ссылка на справочник
Если ТипЗнч(ЗначениеХарактеристики) = Тип("СправочникСсылка.ДополнительныеЗначения") Тогда
ЧисловойРезультат = Число(ЗначениеХарактеристики.Наименование);
// Теперь мы можем использовать ЧисловойРезультат в расчетах
КонецЕсли;
Такой подход позволяет сохранить структуру таблиц БД стабильной и компактной, не жертвуя при этом бизнес-логикой приложения.
Мы выяснили, что ограничение длины числа в предопределенных элементах ПВХ — это не баг, а следствие иерархической структуры настроек ОписаниеТипов. Чтобы изменить длину, необходимо сначала расширить границы типа в свойствах корневого объекта ПВХ. Однако, делая это, мы должны помнить о "цене" примитивных типов:
Используйте примитивные типы осознанно и только там, где это не повредит масштабируемости вашей системы. Для тяжелых учетных механизмов всегда отдавайте предпочтение ссылочной аналитике.