Для чего нужен SQL в 1С и когда он действительно необходим

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

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

Как 1С хранит данные и где в этой схеме SQL

В файловом варианте работы база 1С — это один файл 1Cv8.1CD, и прямого SQL-доступа к нему нет. В клиент-серверном варианте платформа разворачивает базу в СУБД: каждый справочник, документ и регистр превращается в одну или несколько таблиц со служебными именами вида _Reference123 или _AccumRg456. Когда пользователь проводит документ или строит отчёт, платформа формирует SQL-запросы к этим таблицам автоматически.

Из этого следуют два практических вывода. Первый: штатный язык запросов 1С — это надстройка, которую платформа транслирует в SQL конкретной СУБД, поэтому качество вашего запроса влияет на скорость работы базы. Второй: сама база доступна и без 1С — средствами SQL Server Management Studio, pgAdmin и подобных инструментов, что открывает возможности для анализа, но создаёт и риски.

Для чего нужен язык запросов 1С внутри конфигурации

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

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

Пример простого запроса к остаткам склада:

ВЫБРАТЬ
Остатки.Номенклатура КАК Номенклатура,
Остатки.КоличествоОстаток КАК Остаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Склад = &Склад) КАК Остатки
ГДЕ
Остатки.КоличествоОстаток > 0

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

Когда нужен прямой SQL к базе данных

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

Типичные сценарии прямого SQL-доступа:

• Внешняя аналитика и BI. Подключение Power BI, Tableau или Excel напрямую к реплике базы для построения дашбордов, не нагружая рабочую 1С.
• Интеграции. Обмен с сайтом, WMS, CRM через представления (view) в базе, когда веб-сервисы 1С не покрывают нужный объём или скорость.
• Диагностика производительности. Анализ планов запросов, поиск долгих операций, блокировок и дублирующихся индексов средствами самой СУБД.
• Администрирование. Резервное копирование, обслуживание индексов, контроль роста базы и журнала транзакций.
• Разовая сверка данных. Поиск расхождений между системами быстрыми выборками по таблицам.

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

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

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

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

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

SQL и производительность: что нужно знать администратору

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

Практический минимум: уметь снимать план выполнения проблемного запроса, находить длительные запросы средствами СУБД (в SQL Server — через Extended Events или динамические представления, в PostgreSQL — через pg_stat_statements), контролировать фрагментацию индексов и размер журнала транзакций. Регламентное обслуживание — обновление статистики и реиндексация — должно выполняться по расписанию, а не «когда стало тормозить».

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

Как проверить здоровье базы на уровне SQL

Длительность типовых операций (проведение документа, отчёт)

Норма

Время стабильно и не растёт неделя к неделе

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

Операции систематически замедляются без роста объёма данных

Блокировки в СУБД

Норма

Кратковременные, снимаются сами

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

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

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

Норма

Контролируемый, усекается по регламенту

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

Неконтролируемый рост, риск переполнения диска

Риски прямого изменения данных через SQL

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

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

Что учить и в каком порядке

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

Маршрут решения

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

Нужен отчёт или выборка внутри 1СИспользуйте язык запросов 1С и СКД — это устойчиво к обновлениям

Нужна аналитика в Power BI или ExcelСоздайте представления в СУБД и дайте доступ только на чтение, лучше по копии или реплике

База тормозит и причина неяснаСнимите план запроса и список активных запросов средствами СУБД, найдите узкое место

Нужно исправить ошибочные данныеТолько штатными средствами 1С: обработка через объекты или корректировочные документы

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

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

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

Чем консоль запросов отличается от SQL Management Studio?

Консоль запросов работает внутри 1С с объектами конфигурации и показывает результат так, как его видит платформа. Management Studio или pgAdmin работают с физическими таблицами СУБД напрямую: там видны индексы, планы выполнения и реальная структура хранения, но нет виртуальных таблиц остатков и срезов.

Безопасно ли давать аналитикам прямой доступ к базе 1С?

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

Что случится, если обновить конфигурацию при наличии прямых SQL-интеграций?

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

Какая СУБД лучше для 1С — SQL Server или PostgreSQL?

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

Поможет ли изучение SQL ускорить медленный отчёт в 1С?

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