SQL и 1С: зачем нужен SQL при работе с 1С

1С:Предприятие в клиент-серверном варианте не хранит данные в файлах само по себе — вся информация лежит в базе данных под управлением СУБД: Microsoft SQL Server, PostgreSQL, Oracle или IBM DB2. Язык SQL — это способ обращения к этой базе напрямую, минуя платформу 1С. Понимание того, как устроена эта связка, нужно администраторам, разработчикам отчётов и интеграторам.

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

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

Как 1С использует SQL-базу данных

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

Структура таблиц в SQL-базе формируется платформой автоматически по метаданным конфигурации. Имена таблиц и полей технические (например, _Document123, _Fld456), а не читаемые названия из конфигуратора. Связь между объектом метаданных и физической таблицей можно получить штатной функцией «Структура хранения базы данных» в конфигураторе.

Зачем нужен SQL, если есть встроенный язык запросов 1С

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

Типовые задачи, где прямой SQL оправдан:

• выгрузка данных в Power BI, Tableau или другое аналитическое ПО без промежуточных файлов;
• сверка данных между 1С и внешними системами (сайт, CRM, WMS) на уровне таблиц;
• диагностика блокировок и медленных запросов средствами СУБД;
• разовый анализ больших объёмов, когда отчёт внутри 1С работает слишком долго;
• аудит: проверка, что фактически записано в базу, без влияния прав и интерфейса 1С.

Встроенный запрос 1С или прямой SQL

Язык запросов 1С

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

Прямой SQL к базе

Подходит для внешней аналитики, интеграций и диагностики. Быстрее на больших объёмах, но игнорирует права 1С и требует понимания структуры хранения.

Штатные механизмы обмена (COM, HTTP, веб-сервисы)

Подходят для регулярных интеграций с записью данных. Медленнее прямого SQL, но сохраняют целостность базы.

Безопасный сценарий: чтение данных напрямую

Чтение через SQL-запросы (SELECT) не изменяет данные и при грамотной организации не мешает работе пользователей. Первое правило — создать в СУБД отдельную учётную запись только с правом чтения. Ни в коем случае не подключайте аналитические инструменты под учётной записью, от имени которой работает сам сервер 1С.

Второе правило — учитывать блокировки. Тяжёлый аналитический запрос в рабочее время может удерживать ресурсы СУБД и замедлять проведение документов у пользователей. Для Microsoft SQL Server часто применяют чтение с подсказкой WITH (NOLOCK) в разовых выгрузках либо настраивают чтение с реплики, если она есть. Понимать последствия NOLOCK нужно: вы можете прочитать промежуточные, ещё не зафиксированные данные.

1. 1
   Создайте в СУБД отдельного пользователя с правами только на чтение (роль db_datareader для MS SQL).
2. 2
   Получите структуру хранения: Конфигуратор → Администрирование → функция «Структура хранения базы данных».
3. 3
   Составьте SELECT-запрос по техническим именам таблиц и полей.
4. 4
   Проверьте запрос на тестовой копии базы и оцените время выполнения.
5. 5
   Настройте подключение из аналитического инструмента под новой учётной записью.
6. 6
   Сверьте результат выгрузки с штатным отчётом 1С за тот же период.

Почему нельзя изменять данные напрямую в SQL

Прямые команды INSERT, UPDATE и DELETE в базе 1С — самая частая причина непоправимых повреждений. Платформа поддерживает целостность на своём уровне: последовательности документов, итоги регистров, служебные таблицы, версии объектов. Изменение одной таблицы в обход платформы оставляет остальные в несогласованном состоянии.

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

SQL для диагностики производительности

Когда 1С «тормозит», причина почти всегда видна на уровне СУБД: долгие запросы, взаимоблокировки, нехватка индексов для конкретных выборок. Администратору здесь не обойтись без SQL-инструментов: планы выполнения запросов, динамические административные представления в MS SQL Server, журналы медленных запросов в PostgreSQL.

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

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

Как проверить здоровье связки 1С и SQL

Время выполнения типовых отчётов

Норма

Стабильно изо дня в день, без резких скачков

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

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

Взаимоблокировки (deadlock) в логах СУБД

Норма

Единичные случаи или отсутствуют

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

Регулярные взаимоблокировки в часы пик

Фрагментация индексов и актуальность статистики

Норма

Регламентные задания обслуживания выполняются по расписанию

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

Обслуживание не настроено, статистика устарела

Размер журнала транзакций

Норма

Контролируется резервным копированием журнала

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

Журнал растёт и занимает весь диск

Регламентное обслуживание SQL-базы под 1С

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

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

Кому и в каком объёме учить SQL для работы с 1С

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

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

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

Можно ли работать с 1С без SQL-сервера вообще?

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

Какую СУБД выбрать для 1С: MS SQL или PostgreSQL?

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

Как узнать, какой таблице SQL соответствует документ или регистр 1С?

В конфигураторе есть штатная функция «Структура хранения базы данных» (меню «Администрирование»). Она показывает соответствие объектов метаданных физическим таблицам и полям. Ориентироваться по техническим именам вроде _Document или _Fld без этой таблицы соответствия не стоит.

Безопасно ли читать данные с помощью WITH (NOLOCK)?

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

Что делать, если данные уже изменили напрямую в SQL и база работает странно?

Остановите дальнейшие прямые вмешательства. Если есть резервная копия до момента изменения — оцените возможность восстановления. Запустите штатную проверку «Тестирование и исправление» на копии базы, но помните: она не всегда устраняет последствия ручных правок. В сложных случаях потребуется специалист по восстановлению данных 1С.

Нужно ли знать SQL, чтобы писать отчёты в 1С?

Нет, отчёты строятся на встроенном языке запросов и СКД. Но базовое понимание SQL помогает понимать, почему запрос работает медленно, и как его перестроить: какие соединения таблиц дорогие и где не хватает индекса.