Какие существуют подводные камни при использовании определяемых типов в 1С?

Определяемые типы в платформе 1С:Предприятие 8.3 — это мощный механизм, который позволяет разработчику создать «псевдоним» для составного типа данных и использовать его в различных местах конфигурации. На первый взгляд, это кажется идеальным решением: мы один раз описываем набор объектов (например, «Документы со статусами») и используем его в регистрах, реквизитах и коде. Однако за этим удобством скрываются серьезные технические нюансы. В этой статье мы подробно разберем по шагам, с какими «граблями» может столкнуться программист 1С при работе с этим объектом метаданных.

Что такое определяемый тип на самом деле?

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

Рассмотрим пример. Если у вас есть регистр сведений СтатусыДокументов, где измерение Документ имеет определяемый тип ДокументыОборот, то добавление нового документа в этот тип автоматически расширит тип измерения в регистре. Это избавляет от необходимости вручную править десятки объектов метаданных.

Главная опасность: потеря данных при реорганизации

Самая большая проблема, которую мы должны обсудить, — это риск безвозвратной потери данных. Выясним причину, почему это происходит при реорганизации информации. Когда вы исключаете какой-либо объект (например, Документ.РеализацияТоваровУслуг) из состава определяемого типа, платформа при обновлении конфигурации базы данных воспринимает это как команду на очистку значений этого типа в соответствующих полях.

Важные моменты:

1. Если при обновлении в окне «Реорганизация информации» вы проигнорируете предупреждение и нажмете «Принять», данные в колонках с этим типом будут стерты навсегда для удаленного объекта.
2. В сложных конфигурациях, таких как ERP, определяемые типы используются повсеместно. Ошибка при обновлении может стоить потери аналитики в ключевых регистрах.
3. Восстановление данных после такой ошибки без наличия свежей копии базы практически невозможно и требует ручного сопоставления ссылок из бэкапа.

Архитектурные проблемы и производительность SQL

Посмотрим на ситуацию с точки зрения СУБД. Поскольку определяемый тип превращается в составной тип на уровне SQL-таблицы, он наследует все проблемы «широких таблиц».

Проанализируем, как это влияет на производительность SQL:

• Раздувание таблиц: Для каждого типа, входящего в состав определяемого, SQL создает дополнительные колонки (или одну сложную колонку в зависимости от версии). Если в типе 50 документов, выборка данных по такому полю через ВЫБРАТЬ * становится крайне тяжелой операцией.
• Индексация: Поиск и фильтрация по составным полям всегда работают медленнее, чем по простым ссылочным полям. Индексы на таких полях занимают значительно больше места и требуют больше ресурсов при обновлении.
• Типизация чисел и строк: Если вы включили в определяемый тип примитивные типы, например Число или Строка, платформа возьмет максимально возможную длину. Если в одном месте вы планировали строку длиной 10 символов, но в составе типа есть строка неограниченной длины, то все реквизиты станут неограниченными, что может сломать индексацию.

Трудности поиска ссылок в Конфигураторе

Рассмотрим практическое неудобство при разработке. Стандартный механизм «Поиск ссылок на объект» в конфигураторе работает с определяемыми типами нелинейно. Если вы ищете, где используется конкретный документ, поиск покажет вам определяемый тип. Однако, чтобы понять, в каких регистрах или формах используется сам этот тип, вам придется делать второй поиск уже по самому определяемому типу.

Это усложняет анализ влияния изменений. Окно первого поиска закроется, и вам придется держать в голове или записывать связи объектов. Профессиональные инструменты разработки (например, ИР или EDT) частично решают эту проблему, но в стандартном конфигураторе это остается серьезным затруднением при контроле структуры данных.

Особенности работы с расширениями

Работа с расширениями — это зона повышенного внимания. Разберем основные риски при использовании расширений:

1. Конфликты при обновлении: Если вы добавили свой объект в типовой определяемый тип через расширение, при обновлении основной конфигурации 1С может изменить состав этого типа. Это часто приводит к конфликтам, которые требуют ручного вмешательства.
2. Удаление расширения: Если данные были записаны с использованием типа из расширения, а затем расширение было отключено или удалено, вы получите «битые ссылки» (Объект не найден) в тех полях, где использовался этот тип.

Программная работа с определяемыми типами

Выясним, как правильно работать с этими типами в коде. Часто возникает задача создать программно описание типов на основе определяемого типа. Рассмотрим правильный и неправильный подходы.

Неправильно пытаться создать описание типа через строковое имя, так как оно может измениться или не распознаться платформой напрямую. Правильный способ — обращение через метаданные:

// Получаем описание типов на основании определяемого типа "МойТип"
Описание = Метаданные.ОпределяемыеТипы.МойТип.Тип;

// Пример использования при создании колонки таблицы значений
ТЗ = Новый ТаблицаЗначений;
ТЗ.Колонки.Добавить("ОбъектХранения", Описание);

Также важно помнить, что вы не можете создать иерархию: нельзя включить один ОпределяемыйТип в состав другого ОпределяемогоТипа. Платформа запрещает вложенность для упрощения структуры метаданных.

Влияние на интерфейс и СКД

Проанализируем, как использование таких типов отражается на пользователях. В системе компоновки данных (СКД) или в обычных формах при выборе значения в поле с определяемым типом пользователю сначала предлагается выбрать сам тип объекта из огромного списка.

Если в ваш определяемый тип входит 50+ видов документов, это превращается в кошмар для пользователя. Поиск нужного типа документа в длинном списке замедляет работу. Чтобы этого избежать, разработчикам приходится программно ограничивать список доступных типов в формах, что частично нивелирует удобство использования самих определяемых типов.

Итоги и рекомендации

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

• Используйте определяемые типы только там, где действительно предполагается частое расширение состава объектов (например, системы логирования, статусов, бизнес-процессов).
• Никогда не игнорируйте окно «Реорганизация информации» при обновлении базы данных. Тщательно проверяйте, какие именно типы удаляются из состава.
• Старайтесь не включать в определяемые типы примитивные типы (строки, числа, даты) без крайней необходимости, чтобы не раздувать SQL-таблицы.
• Помните о производительности: если в типе слишком много объектов, запросы к таблицам с этим типом могут замедлиться.

Соблюдая эти правила, мы сможем эффективно использовать гибкость платформы 1С, минимизируя риски для стабильности и производительности системы.