Как использовать уникальный идентификатор в качестве измерения регистра накопления?

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

Вариант 1: Использование Уникального идентификатора в виде строки

Самый очевидный способ, который часто выбирают разработчики, — это преобразование UUID в строку. Давайте рассмотрим, как это реализовать технически. Поскольку нам нужно хранить стандартный GUID, длина строки должна составлять 36 символов.

Для реализации этого метода выполним следующие шаги:

1. В конфигураторе добавим в регистр накопления новое измерение, например, ИдентификаторУслуги.
2. Установим тип данных — Строка, длина — 36, допустимые символы — Переменная.
3. В модуле проведения документа будем генерировать или получать UUID строки и записывать его в регистр.

Проанализируем пример кода для записи движения:

Движение = Движения.ОказанныеУслуги.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
Движение.Период = Дата;
// Преобразуем уникальный идентификатор строки ТЧ в строку 36 символов
Движение.ИдентификаторУслуги = Строка(СтрокаТЧ.КлючСвязиUUID);
Движение.Сумма = СтрокаТЧ.Сумма;

Важный нюанс: Помните, что УникальныйИдентификатор не является ссылочным типом. Если вы просто запишете Новый УникальныйИдентификатор(), вы получите уникальную последовательность, но потеряете связь с объектом, если он не сохранен в самой табличной части документа.

Вариант 2: Использование числового ключа связи (метод типовых конфигураций)

Давайте посмотрим на то, как эта задача решена в современных типовых решениях, таких как 1С:ERP 2.5 или УТ 11. Вместо тяжелых строковых идентификаторов разработчики фирмы "1С" используют числовой реквизит КлючСвязи. Это гораздо более эффективный метод с точки зрения производительности СУБД.

Рассмотрим алгоритм работы с ключом связи:

1. В табличную часть документа добавляется реквизит КлючСвязи (тип: Число).
2. В регистр накопления добавляется измерение с аналогичным типом.
3. При заполнении документа или при его записи каждой строке присваивается порядковый номер (или уникальное число в рамках документа).

Этот подход позволяет избежать хранения 72 байт (в Unicode для строки 36 символов) на каждую запись регистра. Числовой идентификатор занимает значительно меньше места и обрабатывается SQL-сервером в разы быстрее.

Почему использование UUID как измерения может быть опасным?

Проанализируем ситуацию с точки зрения архитектуры базы данных. Регистр накопления — это не просто таблица записей, это механизм, который рассчитывает итоги. Использование уникального идентификатора в качестве измерения создает серьезную проблему — раздувание таблицы итогов.

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

• Лавинообразный рост размера базы данных: Таблица итогов по размеру догонит таблицу движений.
• Деградация производительности при проведении: Системе придется обновлять итоги для каждой уникальной записи, что создает колоссальную нагрузку на дисковую подсистему и СУБД.
• Бессмысленность итогов: Получение остатков на текущую дату будет работать так же медленно, как простой перебор записей, так как агрегация (свертка) по уникальному UUID невозможна.

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

Разберем по шагам, какой метод выбрать в зависимости от ваших задач:

1. Если нужна связь со строкой документа: Используйте числовой КлючСвязи. Это стандарт де-факто в современной разработке на 1С. Он позволяет связать движение регистра с конкретной строкой ТЧ, не нагружая систему.
2. Если нужно идентифицировать объект, которого нет в базе (внешняя система): В этом случае использование строки (36) оправдано, но старайтесь не делать такое поле измерением, если по нему не требуются остатки. Если вам нужно просто хранить информацию, используйте Реквизит регистра, а не Измерение. Реквизиты не входят в таблицу итогов и не замедляют расчеты.
3. Если услуга — это справочник: Всегда лучше использовать ссылку на элемент справочника (СправочникСсылка). Ссылочные типы в 1С на уровне СУБД хранятся как binary(16), что гораздо компактнее и быстрее строки.

Пример реализации связи через номер строки

Если структура вашего документа стабильна (строки не удаляются и не пересортировываются после проведения), можно использовать номер строки табличной части. Посмотрим на пример кода в модуле проведения:

Для Каждого ТекСтрока Из Товары Цикл
    Движение = Движения.Запасы.Добавить();
    Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
    Движение.Период = Дата;
    Движение.Номенклатура = ТекСтрока.Номенклатура;
    // Используем номер строки как ключ связи
    Движение.НомерСтрокиДокумента = ТекСтрока.НомерСтроки;
    Движение.Количество = ТекСтрока.Количество;
КонецЦикла;

Однако помните, что при интерактивной сортировке табличной части пользователем НомерСтроки может измениться. Чтобы избежать "битых" связей, рекомендуется записывать фиксированный идентификатор в реквизит строки при ее создании, как мы обсуждали во втором варианте.

Подведем итог: Технически использовать УникальныйИдентификатор как строку в измерении можно, но делать это стоит только в исключительных случаях, понимая риски замедления системы. В большинстве задач оптимальным решением будет использование числового ключа связи или ссылки на объект.