1С как база данных: как устроено хранение данных и как с ним работать

Фраза «1С как база данных» обычно означает один из трёх сценариев: администратор хочет понять, где физически лежат данные информационной базы; интегратор планирует читать данные 1С из внешней системы; разработчик решает, как устроен обмен между 1С и другой СУБД. Во всех случаях ключевой факт один: 1С — это не самостоятельная СУБД, а прикладная платформа, которая хранит данные либо в собственном файловом формате, либо во внешней системе управления базами данных.

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

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

Файловый режим: база как один файл

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

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

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

Клиент-серверный режим и поддерживаемые СУБД

В клиент-серверном варианте между пользователями и данными появляется сервер 1С:Предприятия, который обращается к внешней СУБД. Платформа официально поддерживает Microsoft SQL Server, PostgreSQL (включая сборки, адаптированные под 1С), Oracle Database и IBM Db2. Выбор СУБД влияет на стоимость лицензий, требования к администрированию и тонкости настройки, но не на логику работы прикладного решения.

Наиболее распространённая связка — сервер 1С плюс MS SQL Server: для неё больше всего практических материалов и готовых регламентов обслуживания. PostgreSQL выбирают ради снижения стоимости лицензий; при этом важно использовать сборку, совместимую с платформой, а не «ванильный» дистрибутив, иначе возможны ошибки при развёртывании и обновлении.

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

Как 1С отображает объекты на таблицы СУБД

Каждому объекту конфигурации соответствует одна или несколько таблиц в базе данных. Справочник превращается в таблицу вида _Reference..., документ — в _Document..., регистр накопления — в таблицу итогов и таблицу движений. Имена таблиц содержат числовые идентификаторы, которые платформа назначает автоматически, поэтому сопоставление «объект конфигурации — физическая таблица» неочевидно.

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

СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Строка Из СтруктураХранения Цикл
    Сообщить(Строка.ИмяТаблицыХранения + " <- " + Строка.ИмяТаблицы);
КонецЦикла;

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

Когда допустимо читать данные напрямую из СУБД

Чтение напрямую из таблиц SQL — распространённая практика для выгрузок в хранилища данных, BI-системы и отчётность, когда штатные механизмы 1С не дают нужной скорости. Такое чтение относительно безопасно, если соблюдены три условия: используется отдельная учётная запись только с правом SELECT, запросы не выполняются в момент регламентных операций с базой, и учитываются служебные поля платформы.

Альтернативы прямому чтению, которые не требуют лазать в структуру хранения: HTTP-сервисы и веб-сервисы, публикуемые из 1С, стандартный интерфейс OData, который платформа умеет включать штатно, а также планы обмена и формат EnterpriseData. Для большинства интеграций OData или HTTP-сервисы — более устойчивый путь: они не ломаются при обновлении конфигурации, тогда как прямые SQL-запросы зависят от физических имён таблиц, которые могут измениться.

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

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

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

Практический порядок организации доступа к данным

Если задача — наладить обмен или отчётность поверх базы 1С, действуйте от безопасных механизмов к рискованным, а не наоборот. Сначала проверьте, закрывает ли задачу штатная публикация OData или HTTP-сервис; только если производительности недостаточно, рассматривайте прямое чтение из СУБД с отдельной учётной записью.

1. 1
   Определите режим базы: файловый или клиент-серверный, и какая СУБД используется.
2. 2
   Проверьте штатные механизмы интеграции: OData, HTTP-сервисы, планы обмена.
3. 3
   Если нужен прямой доступ к SQL — получите структуру хранения через ПолучитьСтруктуруХраненияБазыДанных().
4. 4
   Создайте в СУБД учётную запись только с правом чтения нужных таблиц.
5. 5
   Напишите запросы с учётом служебных полей: пометка удаления, проведение, периоды регистров.
6. 6
   Сверьте результаты выборок с отчётами внутри 1С на контрольном периоде.
7. 7
   Задокументируйте запросы и добавьте их проверку в регламент обновления конфигурации.

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

Резервное копирование и обслуживание

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

Клиент-серверная база требует регулярного обслуживания СУБД: обновления статистики, перестроения индексов, контроля роста журнала транзакций. Без этого производительность постепенно деградирует даже при неизменном числе пользователей. Регламентные задания 1С (тестирование и исправление, очистка устаревших данных) планируйте на часы минимальной нагрузки.

Частые вопросы