В практике разработки на платформе 1С:Предприятие часто возникает вопрос: зачем вендор оставил возможность создавать независимый непериодический регистр сведений, в котором не определено ни одно измерение? На первый взгляд, это кажется избыточным, ведь для хранения одиночных значений существуют константы. Однако такой подход является мощным архитектурным инструментом. В этой статье мы подробно разберем, как работает этот механизм, в каких сценариях он незаменим и почему его часто предпочитают пакету обычных констант.
Давайте проанализируем, что представляет собой такой объект с точки зрения структуры данных. В обычном регистре сведений уникальность записи определяется комбинацией его измерений (и периода, если регистр периодический). Если мы создаем регистр без измерений, то «ключ уникальности» становится пустым. Это означает, что в таблице базы данных может существовать только одна-единственная запись. Любая попытка добавить новую запись технически превращается в перезапись существующей.
Рассмотрим основные характеристики такого объекта:
Часто программисты называют такой регистр «группой констант». С точки зрения пользователя это действительно так, но для разработчика есть существенные различия. Выясним причины, по которым регистр может быть предпочтительнее:
1. Группировка прав доступа. Представим, что у нас есть 10 параметров подключения к внешней системе (адрес, порт, логин, пароль и т.д.). Если создавать их константами, нам придется настраивать права (Чтение/Изменение) для каждой из 10 констант в каждой роли. В случае с регистром мы устанавливаем права один раз на весь объект, что значительно упрощает поддержку кода и системы безопасности.
2. Логическая целостность. Параметры в регистре всегда читаются и записываются вместе. Это исключает ситуацию, когда одна константа обновилась, а вторая — нет из-за ошибки в коде или сбоя. Мы работаем с единым набором данных.
3. Хранение в СУБД. На уровне базы данных (SQL) константы могут храниться в одной общей таблице (в зависимости от версии платформы и режима конфигурации), что иногда создает избыточные блокировки при одновременном обращении к разным константам. Регистр сведений — это всегда отдельная физическая таблица, что позволяет более тонко управлять производительностью.
Разберем ситуацию, где использование регистра без измерений является стандартом де-факто. Типичный пример — Параметры интеграции. Рассмотрим структуру регистра ПараметрыПодключенияКСервису:
АдресСервера (Строка)Порт (Число)ИспользоватьПрокси (Булево)Таймаут (Число)ТокенАвторизации (Строка)В типовых конфигурациях и Библиотеке Стандартных Подсистем (БСП) подобные регистры встречаются довольно часто. Например, регистр БлокировкиСеансовОбластейДанных. Он используется для хранения состояния блокировки всей области данных. Здесь не нужны измерения, так как блокировка либо включена (запись есть и заполнена), либо выключена.
Еще один интересный пример — Флаги миграции или обновления. Когда системе нужно запомнить, на каком этапе находится длительный процесс (например, номер последней обработанной порции данных), такой регистр идеально подходит для хранения «курсора» процесса.
Посмотрим на особенности программного взаимодействия. Поскольку измерений нет, наиболее эффективным способом работы является использование МенеджераЗаписи. Нам не нужно строить сложные запросы или отборы.
Проанализируем пример кода для чтения и записи данных:
// Чтение данных из регистра без измерений
Менеджер = РегистрыСведений.ПараметрыИнтеграции.СоздатьМенеджерЗаписи();
Менеджер.Прочитать();
Если Менеджер.Выбран() Тогда
// Запись существует, работаем с ресурсами
ТекущийАдрес = Менеджер.АдресСервера;
Иначе
// Записи еще нет, можно задать значения по умолчанию
ТекущийАдрес = "https://api.default.com";
КонецЕсли;
// Изменение и сохранение данных
Менеджер.АдресСервера = "https://api.new-server.com";
Менеджер.Таймаут = 30;
Менеджер.Записать();
Обратите внимание на метод Прочитать(). В данном контексте он всегда пытается найти ту самую единственную строку. Если вы вызовете Записать(), платформа автоматически выполнит операцию UPSERT (обновит существующую или создаст новую, если таблицы пуста).
Важно прояснить спор, часто возникающий на форумах: контролирует ли платформа уникальность ресурсов? Нет, ресурсы никогда не входят в ключ уникальности. Ключ в данном случае — это «отсутствие измерений». Попытка создать вторую запись через НаборЗаписей не приведет к ошибке дублирования, а просто заменит содержимое регистра.
С точки зрения транзакционных блокировок, использование регистра без измерений требует осторожности в высоконагруженных системах. При записи в такой регистр блокируется вся таблица целиком (так как в ней всего одна строка). Если сотни пользователей одновременно попытаются обновить разные поля в этом регистре, возникнут очереди и ожидания. В таких специфических случаях лучше распределить данные по разным константам или использовать регистры с измерениями (например, разделяя настройки по пользователям или узлам).
Мы выяснили, что отсутствие измерений в непериодическом регистре сведений — это не ошибка проектирования, а осознанный инструмент платформы. Рассмотрим основные выводы:
МенеджерЗаписи, это наиболее лаконичный и быстрый способ.Таким образом, регистр без измерений — это «супер-константа», позволяющая структурировать параметры системы и делать архитектуру решения более чистой и понятной.