SQL и 1С: как работать с базой данных

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

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

Как 1С хранит данные в SQL-базе

Каждый объект конфигурации отображается на одну или несколько таблиц СУБД. Справочник «Номенклатура» становится таблицей вида _Reference123, документ «Реализация товаров» — таблицей _Document456, а его табличная часть — отдельной таблицей с суффиксом _VT. Регистры накопления и сведений хранятся как таблицы _AccumRg и _InfoRg, для регистров с итогами создаются дополнительные служебные таблицы.

Имена таблиц и полей генерируются платформой и не совпадают с именами метаданных. Сопоставление «таблица SQL → объект конфигурации» можно получить через функцию «ПолучитьСтруктуруХраненияБазыДанных()» в конфигураторе или через обработки, показывающие структуру хранения. Без этого сопоставления ориентироваться в базе на уровне SQL практически невозможно.

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

Язык запросов 1С вместо «чистого» SQL

Основной инструмент выборки данных в 1С — встроенный язык запросов. Он похож на SQL синтаксически (SELECT, WHERE, JOIN, GROUP BY имеют аналоги), но работает с объектами метаданных, а не с физическими таблицами: вы пишете ВЫБРАТЬ ... ИЗ Документ.РеализацияТоваровУслуг, а платформа сама преобразует это в SQL с нужными соединениями таблиц.

Язык запросов 1С поддерживает виртуальные таблицы — например, РегистрНакопления.ТоварыНаСкладах.Остатки или .Обороты с параметрами периода. Это готовые агрегаты, которые вручную на SQL пришлось бы собирать из нескольких таблиц с группировками. Использование виртуальных таблиц — главный способ писать быстрые отчёты без погружения в физическую структуру.

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

Когда нужен прямой доступ к SQL

Прямая работа с СУБД оправдана в административных задачах: резервное копирование средствами SQL Server, перестроение индексов, обновление статистики, анализ блокировок через системные представления (sys.dm_tran_locks, sp_who2), поиск долгих запросов через Extended Events или Profiler. Эти операции выполняет администратор базы данных, и они не трогают прикладные данные.

Второй легитимный сценарий — аналитическая выгрузка на чтение: подключение Power BI, Excel или скрипта к реплике базы для построения отчётности вне 1С. Здесь критично работать с копией или read-only репликой, а не с рабочей базой, и понимать, что структура таблиц может измениться после обновления конфигурации — выгрузка «привязана» к конкретной версии структуры.

Безопасное чтение данных через SQL

Если задача — разово выгрузить данные, безопасный порядок такой: определить нужные объекты конфигурации, получить сопоставление имён таблиц через структуру хранения, сформировать SELECT-запрос к этим таблицам и выполнить его на копии базы или с подсказкой WITH (NOLOCK) на рабочей, чтобы не создавать блокировок. Учтите, что NOLOCK даёт «грязное чтение» — для точной отчётности лучше копия.

Удалённые пометки учитывайте вручную: помеченные на удаление документы физически присутствуют в таблице с флагом _Marked. Аналогично поле _Posted показывает, проведён ли документ. Фильтры по этим полям заменяют логику, которую платформа добавляет автоматически.

1. 1
   Сделайте резервную копию базы средствами СУБД или поднимите тестовую копию
2. 2
   В конфигураторе выполните ПолучитьСтруктуруХраненияБазыДанных() и найдите имена таблиц нужных объектов
3. 3
   Составьте SELECT-запрос с фильтрами по _Posted и _Marked
4. 4
   Выполните запрос на копии базы и сверьте результат с отчётом в 1С
5. 5
   Только после проверки используйте выгрузку в рабочих целях

Диагностика производительности: где SQL помогает 1С

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

Дальше проблемный запрос анализируют в SQL Server Management Studio: смотрят план выполнения, ищут сканирования таблиц вместо поиска по индексу, проверяют актуальность статистики. Частые причины медленной работы — запросы к виртуальным таблицам без заданного периода, соединения по невычисляемым условиям и избыточное получение всех полей вместо нужных.

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

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

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

Норма

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

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

Резкие скачки длительности при тех же данных

Блокировки в sp_who2 / Activity Monitor

Норма

Единичные кратковременные блокировки

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

Длинные цепочки ожиданий, взаимоблокировки

План выполнения запроса

Норма

Index Seek по ключевым полям

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

Table Scan / Clustered Index Scan по большим таблицам

Типичные ошибки при совместной работе SQL и 1С

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

Вторая группа ошибок — административная: бэкап только через выгрузку в dt без SQL-копии (или наоборот, без тестового восстановления), отключённый autogrowth или переполненный журнал транзакций, регламентные задания 1С, запущенные одновременно с перестроением индексов. Эти сценарии не ломают данные мгновенно, но создают риск потери базы или остановки работы пользователей.

FAQ

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

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

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

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

Как узнать, в какой таблице SQL лежит нужный справочник?

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

Безопасно ли подключать Power BI напрямую к базе 1С?

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

Что делать, если 1С стала медленно проводить документы?

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