Как связаны объекты конфигурации и объекты базы данных 1С

Когда разработчик добавляет в конфигураторе новый справочник или документ, он описывает лишь метаданные — декларативное представление о том, какие данные будут храниться и как с ними работать. Реальные записи хранятся в таблицах базы данных, которые платформа 1С создаёт и поддерживает автоматически. Понимание этой двухуровневой модели — основа для безопасного обновления конфигураций, диагностики ошибок и работы с большими объёмами данных.

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

Ниже разобрано, как именно платформа отображает объекты конфигурации на таблицы СУБД, что происходит при обновлении, какие ситуации опасны и как проверить согласованность структуры.

Что такое объект конфигурации и что такое объект базы данных

Объект конфигурации — это элемент дерева метаданных в конфигураторе: справочник, документ, регистр сведений, регистр накопления, план счетов и так далее. Он определяет состав реквизитов, табличных частей, измерений и ресурсов, поведение объекта, формы и права доступа. Всё это хранится в файле конфигурации (в информационной базе — в служебных таблицах, содержащих описание метаданных).

Объект базы данных — это таблицы, индексы и записи на уровне СУБД (в клиент-серверном варианте — MS SQL Server, PostgreSQL, Oracle, IBM Db2; в файловом — собственный формат 1Cv8.1CD). Пользователь и прикладной код не обращаются к этим таблицам напрямую: платформа сама транслирует запросы на встроенном языке в SQL-запросы к физическим таблицам.

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

Как платформа отображает объекты конфигурации на таблицы

Платформа формирует имена физических таблиц по служебным правилам: префикс типа объекта и внутренний числовой идентификатор. Например, справочники получают префикс вида _Reference, документы — _Document, регистры сведений — _InfoRg, регистры накопления — _AccumRg, с добавлением номера объекта. Разработчику прикладного решения эти имена обычно не нужны, но их знание помогает при диагностике на уровне СУБД.

Соответствие между типами метаданных и набором таблиц удобно представить в виде сопоставления:

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

Две конфигурации: основная и конфигурация базы данных

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

Увидеть расхождение можно в конфигураторе: меню «Конфигурация → Конфигурация базы данных» позволяет открыть и сравнить обе версии. Если объекты отличаются, платформа предложит выполнить обновление. В режиме предприятия работа всегда идёт по конфигурации базы данных — новые реквизиты, добавленные только в основную конфигурацию, пользователям недоступны.

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

Что происходит при обновлении конфигурации базы данных

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

Типичный порядок действий при обновлении выглядит так:

1. 1
   Сделайте резервную копию базы (выгрузку в dt или средствами СУБД)
2. 2
   Завершите работу пользователей или запланируйте обновление на нерабочее время
3. 3
   Внесите изменения в основную конфигурацию и выполните проверку конфигурации
4. 4
   Запустите «Обновить конфигурацию базы данных» (F7) и изучите список изменений структуры
5. 5
   При наличии динамического обновления оцените, допустимо ли оно для ваших изменений
6. 6
   Дождитесь завершения реструктуризации и проверьте работу ключевых операций

Динамическое обновление применяется, когда изменения не затрагивают структуру таблиц (например, изменены только модули или формы). Если структура меняется, потребуется монопольный доступ — платформа сообщит об этом явно, и пытаться обойти это требование не следует.

Реструктуризация: риски и типичные ошибки

Реструктуризация — самая уязвимая точка связи между метаданными и таблицами. Платформа создаёт новые версии таблиц, переносит данные и удаляет старые. Прерывание процесса (отключение питания, разрыв соединения с сервером СУБД, нехватка дискового пространства) может оставить базу в несогласованном состоянии, когда часть таблиц уже преобразована, а часть — нет.

Отдельно стоит предостеречь от прямой работы с таблицами через SQL. Платформа хранит служебные поля, версии данных и внутренние идентификаторы, смысл которых не документирован для прямого изменения. Чтение данных запросами к СУБД для аналитики относительно безопасно, а вот любые INSERT, UPDATE или DELETE в обход платформы почти гарантированно приводят к рассогласованию итогов, регистрации обменов и механизмов версионирования.

Как проверить согласованность метаданных и базы данных

После обновления или при подозрении на рассинхронизацию полезно выполнить несколько проверок. Первая — сравнение основной конфигурации и конфигурации базы данных: они должны совпадать. Вторая — тестирование и исправление информационной базы (режим «Тестирование и исправление» в конфигураторе) с проверкой логической и ссылочной целостности. Третья — функциональная проверка: открытие типовых форм, проведение документов, построение отчётов по изменённым регистрам.

Контрольные точки

Как проверить результат

Сравнение конфигураций

Норма

Основная конфигурация и конфигурация БД идентичны

Тревожный признак

Есть различия — обновление не завершено или отменено

Сообщение при запуске предприятия

Норма

База открывается без предупреждений о структуре

Тревожный признак

Ошибки вида «Поле не найдено» или несоответствие версий

Проведение документов по регистрам

Норма

Движения формируются, итоги сходятся

Тревожный признак

Ошибки записи, расхождение оборотов и итогов

Тестирование и исправление

Норма

Проверки завершаются без ошибок

Тревожный признак

Обнаружены битые ссылки или ошибки логической целостности

Если тестирование выявляет ошибки, не спешите ставить флажки исправления на всех проверках: сначала оцените, какие данные будут изменены, и выполните исправление на копии базы. Очистка ссылок, например, может удалить записи, которые на самом деле нужно было восстановить.

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

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

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

Подходы к изменению структуры

Добавление нового реквизита

Безопасный сценарий: быстрая реструктуризация, данные не затрагиваются

Изменение типа существующего поля

Требует полной реструктуризации таблицы; на больших таблицах выполняйте в нерабочее время

Удаление реквизита

Данные теряются безвозвратно; предпочтительнее прекратить использование и удалить позже

Обходное решение через дополнительные сведения

Не меняет структуру таблиц, но усложняет запросы и отчёты

Перед массовой реструктуризацией на клиент-серверной базе убедитесь, что на дисках СУБД достаточно свободного места: в процессе переноса данных таблица фактически дублируется, и нехватка места — одна из самых частых причин обрыва обновления.

Часто задаваемые вопросы

Можно ли изменить таблицу 1С напрямую через SQL-запрос?

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

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

Изменения внесены только в основную конфигурацию. Нужно выполнить обновление конфигурации базы данных (клавиша F7 в конфигураторе) — только после этого поле появится в физической таблице и станет доступно в режиме предприятия.

Что такое динамическое обновление и когда оно допустимо?

Это обновление конфигурации базы данных без завершения сеансов пользователей. Оно возможно, только если изменения не затрагивают структуру таблиц: например, изменены модули, формы или макеты. Добавление реквизита или регистра уже требует монопольного режима.

Сколько таблиц создаёт один документ с табличной частью?

Минимум две: таблицу шапки и таблицу табличной части. Если документ делает движения по регистрам, записи попадают в таблицы этих регистров, но отдельных таблиц под каждый документ для движений не создаётся.

Чем опасно прерывание реструктуризации?

База может остаться в промежуточном состоянии: часть таблиц преобразована, часть — нет. Восстановление обычно возможно только из резервной копии, поэтому перед обновлением со структурными изменениями копия обязательна.

Создают ли отчёты и обработки таблицы в базе данных?

Нет. Отчёты и обработки — это объекты логики, они не хранят прикладные данные и не порождают таблиц. Данные они читают из таблиц, созданных под справочники, документы и регистры.