1С и SQL: что это такое и как они работают вместе

Запрос «1С SQL что такое» обычно означает одно из двух: либо человек хочет понять, как программа 1С хранит свои данные в базе SQL-сервера, либо ему нужно разобраться, как из 1С обращаться к базе напрямую запросами. Оба смысла связаны с одним фундаментом — платформа 1С:Предприятие умеет работать в клиент-серверном режиме, где данные хранятся не в файле, а в системе управления базами данных (СУБД).

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

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

Как 1С хранит данные: файловый и клиент-серверный режимы

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

В клиент-серверном режиме данные размещаются в полноценной СУБД, а между пользователями и базой встаёт сервер 1С:Предприятия. Платформа сама формирует SQL-запросы к СУБД, создаёт таблицы, индексы и управляет транзакциями. Администратор видит в SQL Server десятки таблиц с техническими именами вроде _Document123 или _Reference45 — это и есть объекты конфигурации в физическом представлении.

Какие СУБД поддерживает платформа 1С

Платформа 1С:Предприятие работает с несколькими системами управления базами данных. Наиболее распространён вариант Microsoft SQL Server — он исторически стал стандартом де-факто для коммерческих внедрений в Windows-инфраструктуре. Также поддерживаются PostgreSQL (включая адаптированные сборки), IBM DB2 и Oracle Database.

Выбор СУБД влияет на стоимость владения и требования к администрированию. PostgreSQL позволяет снизить затраты на лицензии, но требует специальных сборок и внимательной настройки. MS SQL Server проще в сопровождении для типовых сценариев, но лицензии на него и на сервер 1С составляют заметную часть бюджета. Конкретные поддерживаемые версии СУБД зависят от версии платформы — их нужно сверять с документацией к вашему релизу.

Чем язык запросов 1С отличается от SQL

Внутри конфигурации разработчик пишет запросы на встроенном языке запросов 1С. Внешне он похож на SQL: там есть ВЫБРАТЬ, ИЗ, ГДЕ, СГРУППИРОВАТЬ ПО — прямые аналоги SELECT, FROM, WHERE, GROUP BY. Но оперирует он не физическими таблицами, а логическими объектами: Справочник.Номенклатура, Документ.РеализацияТоваровУслуг, РегистрНакопления.ОстаткиТоваров.

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

ВЫБРАТЬ
	Товары.Ссылка КАК Товар,
	Товары.Код КАК Код
ИЗ
	Справочник.Номенклатура КАК Товары
ГДЕ
	НЕ Товары.ПометкаУдаления

Ключевое отличие в безопасности и целостности: язык запросов 1С позволяет только читать данные. Изменение выполняется через объектную модель — методы Записать(), Провести(), которые выполняют бизнес-логику, контроль прав и проверки заполнения. Прямой UPDATE в SQL обходит все эти механизмы.

Как посмотреть, какие SQL-запросы формирует платформа

Для диагностики производительности полезно видеть, во что превращается запрос 1С на стороне СУБД. В MS SQL Server для этого используется SQL Server Profiler или Extended Events — инструменты трассировки, показывающие реальные запросы, их длительность и планы выполнения. В PostgreSQL аналогичную роль играют логи медленных запросов и расширение pg_stat_statements.

Со стороны 1С есть технологический журнал — механизм логирования событий платформы. Включив события DBMSSQL и EXCP, можно увидеть тексты SQL-запросов с привязкой к контексту кода конфигурации, который их породил. Это основной способ найти «тяжёлый» запрос: сначала фиксируется проблемный SQL, затем по контексту определяется место в коде.

1. 1
   Включите технологический журнал на сервере 1С с событиями DBMSSQL и SDBL с фильтром по длительности
2. 2
   Воспроизведите проблемную операцию в пользовательском режиме
3. 3
   Найдите в журнале запросы с большой длительностью и определите вызывающий их код
4. 4
   Проверьте план выполнения запроса в СУБД: используются ли индексы, нет ли полного сканирования таблиц
5. 5
   Оптимизируйте запрос 1С: добавьте параметры виртуальных таблиц, уберите лишние соединения, проверьте индексацию реквизитов отбора

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

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

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

Администрирование SQL-базы 1С: что важно настроить

Клиент-серверная 1С требует регулярного обслуживания со стороны СУБД. План обслуживания обычно включает обновление статистики, дефрагментацию или перестроение индексов, контроль роста журнала транзакций и регулярное резервное копирование средствами самой СУБД. Модель восстановления базы (simple или full) выбирают исходя из требований к точке восстановления: full даёт возможность отката на произвольный момент времени, но требует регламентного backup журнала.

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

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

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

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