Архитектура хранения свойств объектов в 1С Предприятие

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

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

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

Уровень метаданных: описание структуры объекта

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

Физически описание метаданных хранится в файле 1Cv8.cf (для файловых баз) или в специальных системных таблицах сервера 1С (для клиент-серверного варианта). Внутри этого хранилища свойства описываются в формате XML или бинарном представлении, понятном только платформе.

Когда вы добавляете новый реквизит в справочник "Номенклатура" через конфигуратор, вы меняете именно это описание. Платформа считывает его при запуске в режиме Предприятие и строит на его основе интерфейс и логику работы.

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

Важно различать свойства самого объекта метаданных и свойства экземпляра. Например, свойство "ЭтоГруппа" у элемента справочника описано в метаданных, но его значение (Истина или Ложь) хранится уже в таблице данных.

Физическое хранение в файловой базе данных

В случае использования файлового варианта работы, все данные пользователей хранятся в файле 1Cv8.1CD. Это единый бинарный файл, который содержит таблицы, индексы и служебную информацию. Свойства объектов здесь представлены в виде колонок внутри таблиц.

Структура этого файла закрыта и не предназначена для прямого редактирования сторонними утилитами. Попытка изменить байты внутри 1Cv8.1CD вручную гарантированно приведет к потере данных. Платформа 1С использует собственный механизм транзакций для записи изменений.

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

• 📂 Файл 1Cv8.1CD содержит все табличные данные и индексы.
• 📄 Файл 1Cv8.cdx хранит индексы для ускорения поиска (в старых версиях платформы).
• 🔒 Файл 1Cv8.tmp или 1Cv8log может содержать временные данные или журнал регистрации.
• ⚙️ Файл 1Cv8.1CL хранит список пользователей и настройки лицензирования.

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

Архитектура хранения в клиент-серверном варианте (SQL)

В режиме клиент-сервер архитектура хранения кардинально меняется. Файл 1Cv8.1CD отсутствует. Вместо него платформа 1С использует полноценную систему управления базами данных (СУБД), такую как Microsoft SQL Server, PostgreSQL или Oracle.

Свойства объектов 1С в этом случае хранятся в обычных таблицах реляционной базы данных. При создании конфигурации платформа генерирует SQL-скрипты, создающие таблицы с именами типа _Reference123 или _Document456.

Каждый реквизит объекта становится колонкой в соответствующей таблице. Типы данных 1С преобразуются в типы данных СУБД: строки становятся NVARCHAR, числа — DECIMAL, даты — DATETIME. Это позволяет использовать мощь СУБД для обработки больших объемов данных.

SELECT * FROM _Reference10 WHERE _Marked = 0x00

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

Почему имена таблиц выглядят странно?

Имена таблиц в SQL (например, _Reference8) являются хэшами от имен объектов метаданных. Это сделано для поддержки разных кодировок и сокращения имен, так как в некоторых СУБД есть ограничения на длину идентификаторов.

Табличные части и регистры: особенности структуры

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

Связь между заголовком документа и его строками (табличной частью) осуществляется через ссылку на документ. Это позволяет реализовать структуру "один ко многим" без дублирования данных заголовка в каждой строке.

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

Тип объекта 1С	Где хранится в SQL	Особенность хранения
Справочник	Таблица _Reference<ID>	Иерархия хранится в поле _Parent
Документ	Таблица _Document<ID>	Проводки хранятся отдельно в регистрах
Табличная часть	Таблица _AccRg<ID> или _Tab<ID>	Связь по ссылке на родительский объект
Регистр сведений	Таблица _InfoRg<ID>	Периодичность влияет на первичный ключ

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

Системные свойства и служебные поля

Помимо свойств, заданных разработчиком, каждый объект 1С обладает набором системных свойств. Они необходимы для работы платформы и не всегда видны в обычном режиме работы, но присутствуют в базе данных.

К таким свойствам относятся уникальный идентификатор (_IDRRef), пометка удаления (_Marked), версия данных (_Version) и код (для элементов справочников). Эти поля создаются автоматически.

⚠️ Внимание: Никогда не пытайтесь вручную изменить значение поля _Version или _IDRRef через прямой SQL-запрос. Это нарушит механизм блокировок и может сделать объект недоступным для редактирования в режиме 1С.

Свойство "Ссылка" является виртуальным в языке 1С, но физически представлено в базе данных как уникальный идентификатор (GUID). Именно по этому полю происходит связывание всех объектов между собой.

При анализе медленных запросов часто оказывается, что проблема кроется в отсутствии индекса именно по системным полям или неправильном использовании ссылки в условиях отбора.

• 🆔 _IDRRef — уникальный идентификатор записи (UUID).
• 🗑️ _Marked — флаг пометки на удаление (0x00 или 0x01).
• 🔄 _Version — версия строки для контроля целостности данных.
• 📅 _Period — период записи (для регистров с периодичностью).

Знание структуры системных полей позволяет администраторам баз данных проводить глубокую диагностику проблем производительности на уровне СУБД.

Виртуальные таблицы и динамические свойства

В современных конфигурациях 1С широко используются виртуальные таблицы. Они не хранят данные физически в виде отдельной таблицы, а представляют собой представление (View) или выборку из нескольких физических таблиц.

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

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

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

ℹ️ Информация: Интерфейсы и алгоритмы работы виртуальных таблиц могут меняться с выходом новых версий платформы 1С. Всегда сверяйтесь с техническим описанием релиза вашей версии платформы при оптимизации запросов.

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

Можно ли открыть файл 1Cv8.1CD в текстовом редакторе?

Нет, файл 1Cv8.1CD имеет бинарный формат. Открытие его в текстовом редакторе покажет набор нечитаемых символов. Для просмотра данных используйте режим 1С:Предприятие или подключитесь к базе через ODBC, если это файловый вариант с такой возможностью (ограниченно).

Где хранятся картинки и вложенные файлы?

В файловом варианте они хранятся внутри файла 1Cv8.1CD. В клиент-серверном варианте — в специальных таблицах СУБД (обычно с префиксом _Blob или в полях типа IMAGE/VARBINARY), либо во внешнем файловом хранилище, если настроено разделение.

Как узнать имя физической таблицы для объекта 1С?

Имя физической таблицы можно узнать через консоль запросов или администрирование сервера 1С. Также существует таблица метаданных _InfoRg8238 (имя может отличаться), которая хранит соответствие имен объектов и имен таблиц в БД.

Влияет ли добавление реквизита на размер базы данных?

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

Можно ли перенести свойства из одной базы в другую без конфигуратора?

Структуру (свойства) можно перенести через файл выгрузки конфигурации (.cf). Данные (значения свойств) можно перенести через обработку выгрузки/загрузки данных (XML) или прямую миграцию на уровне СУБД, но последнее требует высокой квалификации.