При проектировании метаданных в системе 1С:Предприятие начинающие разработчики часто совершают критическую ошибку: используют строковые поля большой длины (например, путь к файлу или подробное описание) в качестве измерений регистра сведений. На первый взгляд это кажется удобным способом обеспечить уникальность записей, однако на практике такой подход ведет к деградации производительности, невозможности работы в серверном режиме и нарушению базовых стандартов разработки 1С.
Разберем подробно, почему текущая реализация, где путь к файлу длиной 750 символов или избыточные характеристики товара хранятся в измерениях, является ошибочной, и какие аргументы помогут донести это до коллег или руководства.
Проанализируем техническую сторону вопроса. Самый весомый аргумент против длинных строк в измерениях — это физическое ограничение систем управления базами данных (СУБД). Все измерения регистра сведений всегда входят в состав кластерного индекса, который система создает автоматически для обеспечения уникальности записей.
«превышен максимальный размер ключа индекса». База просто откажется работать.Рассмотрим ситуацию с базой в PostgreSQL. Даже если СУБД позволяет создавать индексы большого размера, их производительность будет катастрофически низкой. Системе придется сравнивать огромные объемы данных при каждом поиске, вставке или удалении записи, что приведет к росту времени отклика и частым блокировкам.
Выясним, что говорят официальные стандарты 1С (доступные на ИТС) и специализированная литература, такая как книга «Профессиональная разработка в системе 1С:Предприятие 8». Основные принципы проектирования регистров сводятся к следующим пунктам:
Если нам необходимо хранить путь к файлу или длинное строковое описание, рассмотрим альтернативные варианты реализации, которые соответствуют стандартам:
Вариант 1. Использование реквизитов. Если по пути к файлу не требуется обеспечивать уникальность или выполнять мгновенный поиск, перенесите это поле из раздела «Измерения» в раздел «Реквизиты». В реквизитах строка может иметь неограниченную длину, так как она не участвует в построении индекса.
Вариант 2. Хеширование (MD5/SHA). Если уникальность записи все же должна зависеть от длинной строки, воспользуемся проверенным методом: в измерении будем хранить ХешСумму (длиной 32 или 40 символов), а саму длинную строку — в реквизите. Посмотрим на пример кода для получения хеша:
Функция ПолучитьХешПути(ПутьКФайлу)
Хеширование = Новый ХешированиеДанных(АлгоритмХеширования.MD5);
Хеширование.Добавить(ПутьКФайлу);
Возврат НРег(СтрЗаменить(Строка(Хеширование.ХешСумма), " ", ""));
КонецФункции
Вариант 3. Использование справочника-обертки. Это наиболее гибкое решение. Создадим справочник Файлы (или ПутиКФайлам), где в наименовании или реквизите будет храниться строка любой длины. В регистре сведений в качестве измерения будем использовать тип СправочникСсылка.Файлы. Это позволит минимизировать размер таблицы регистра и ускорить работу индексов.
Для аргументации своей позиции перед руководством крайне полезно использовать инструмент «1С:Автоматизированная проверка конфигураций» (АПК). Это типовое решение от фирмы 1С, предназначенное для аудита кода и структуры метаданных.
Проанализируем работу АПК в данном контексте: в программе заложено стандартное правило «Длина строковых измерений». Система автоматически пометит ваш регистр как ошибочный, если обнаружит в измерениях строки длиной более 100–120 символов. Отчет из АПК является официальным подтверждением того, что конфигурация содержит архитектурные дефекты, которые необходимо исправить перед выпуском или внедрением.
Если теоретических доводов недостаточно, проведем небольшой эксперимент, чтобы показать коллегам «эффект масштаба»:
Резюмируем: Использование длинных строк в измерениях — это «мина замедленного действия». Рано или поздно это приведет к невозможности масштабирования системы. Следуйте стандартам 1С: используйте ссылочные типы, выносите описательные данные в реквизиты и всегда проверяйте конфигурацию инструментами автоматического аудита.