При проектировании систем хранения дополнительных свойств объектов в 1С часто возникает вопрос: можно ли сделать само ЗначениеСвойства измерением регистра сведений? Это кажется удобным для быстрого поиска или отбора, но таит в себе серьезные технические риски, связанные с ограничениями систем управления базами данных (СУБД). Разберем эту ситуацию подробно, проанализируем поведение различных платформ и найдем оптимальные архитектурные решения.
Для начала проанализируем, как 1С:Предприятие работает с данными на уровне СУБД. Любой регистр сведений имеет первичный ключ, который формируется из совокупности его измерений. В терминах SQL-сервера этот ключ становится кластерным индексом. У индексов есть жесткие ограничения по размеру в байтах, которые нельзя игнорировать:
Важно помнить, что 1С использует кодировку Unicode (UTF-16), где каждый символ занимает 2 байта. Таким образом, строка длиной 1024 символа теоретически может занимать 2048 байт, что мгновенно блокирует работу в MS SQL и файловом варианте, если эта строка входит в индекс.
Рассмотрим, что происходит, когда мы назначаем измерению тип Характеристика.ДополнительныеРеквизитыИСведения. Этот тип является составным и ссылается на ПланВидовХарактеристик (ПВХ). Платформа 1С при создании таблиц в СУБД должна зарезервировать место под все возможные типы, указанные в ПВХ.
Если в настройках ПВХ для типа «Строка» указана длина 1024, то при попытке записи длинной строки в измерение регистра возникнет следующая ситуация:
Index Key Size Limit.Проанализируем сообщение №5 из обсуждения: автор отмечает, что в SQL база «вроде бы работает». Это происходит потому, что ошибка возникает не в момент определения структуры, а в момент записи данных. Если вы записываете в это измерение ссылки на справочники или короткие строки, лимит не превышается. Но как только пользователь введет длинный текст — система «упадет».
Если мы обратимся к опыту разработчиков фирмы «1С», то увидим, что в регистре сведений ДополнительныеСведения (или аналогичных) структура выглядит так:
Почему Значение вынесено в ресурсы?
Ресурсы регистра сведений (если они не индексируются принудительно) не входят в состав кластерного индекса. Это позволяет хранить в них данные практически любого объема (включая строки неограниченной длины и ХранилищеЗначения), не опасаясь ограничений СУБД на размер ключа. Это единственный безопасный способ хранения пользовательских характеристик, состав типов которых может меняться в процессе эксплуатации системы.
Иногда бизнес-логика требует именно индексации значения (например, для быстрого поиска объектов по определенному значению свойства). Рассмотрим, как решить эту задачу правильно.
Способ 1. Использование Хеш-суммы
Выясним причину использования хеширования. Если нам нужно искать по длинной строке, мы можем создать дополнительное измерение ХешЗначения с типом Строка(40) или Число. При записи в регистр мы вычисляем хеш (например, MD5) от длинной строки и записываем его в это измерение. Поиск будет осуществляться по хешу, а само длинное значение будет храниться в ресурсе для отображения пользователю.
Пример кода для записи с вычислением хеша:
Процедура ПередЗаписью(Отказ, Замещение)
// Допустим, у нас есть функция ПолучитьMD5(Строка)
ХешЗначения = ПолучитьMD5(Строка(ЗначениеСвойства));
КонецПроцедуры
Способ 2. Ограничение типов в ПВХ
Если вы жестко контролируете состав типов в ПланеВидовХарактеристик и уверены, что длина строки никогда не превысит, например, 50-100 символов, то использование такого типа в измерении допустимо. Однако помните, что любая модификация ПВХ в будущем (увеличение длины строки до 500+) может привести к неработоспособности всей базы данных.
Разберем, к чему приведет игнорирование этих правил:
INSERT и UPDATE. Каждый новый символ в индексе заставляет СУБД тратить больше ресурсов на перестроение дерева индекса.Проанализировав ситуацию, можно сделать однозначный вывод: не используйте тип «Характеристика» в измерениях, если в План Видов Характеристик включены строки большой длины.
Правильный алгоритм действий при проектировании:
Таким образом, мы видим, что технические ограничения СУБД диктуют правила архитектуры приложений. Использование ресурсов для хранения значений характеристик — это не «велосипед», а проверенный стандарт разработки на платформе 1С, обеспечивающий стабильность и производительность системы.