Администрирование · 13 мин
Зачем нужен SQL в 1С и когда без него не обойтись
Зачем нужен SQL в 1С: как устроено хранение данных, когда нужен прямой доступ к СУБД, типичные задачи, риски и безопасные практики работы с базой.
1С:Предприятие не хранит данные внутри себя — вся информация справочников, документов, регистров и настроек физически лежит в базе данных. В файловом варианте это собственный формат платформы, а в клиент-серверном — полноценная СУБД: Microsoft SQL Server, PostgreSQL, Oracle или IBM DB2. Язык SQL — это способ напрямую обратиться к этим таблицам, минуя платформу 1С.
Большинство повседневных задач решается встроенным языком запросов 1С, который по синтаксису напоминает SQL, но работает через объектную модель платформы. Однако существует целый класс ситуаций — администрирование, диагностика производительности, интеграция, миграция данных, — где знание SQL становится обязательным. Понимание того, как 1С хранит данные на уровне СУБД, отличает специалиста, который «нажимает кнопки», от специалиста, который управляет системой.
Материал рассчитан на администраторов, разработчиков и внедренцев, которые работают с клиент-серверными базами 1С и хотят понять, где граница между штатными средствами платформы и прямой работой с SQL, какие задачи решаются на уровне СУБД и как не разрушить базу неосторожным вмешательством.
Как 1С хранит данные в СУБД и почему это важно понимать
При публикации информационной базы на сервере СУБД платформа 1С создаёт набор физических таблиц со служебными именами вида _Document123, _Reference45, _AccumRg678. Каждому объекту метаданных — справочнику, документу, регистру — соответствует одна или несколько таблиц, а соответствие имён хранится в служебной таблице Params и файле структуры базы.
Платформа выступает посредником: когда разработчик пишет запрос на встроенном языке, 1С транслирует его в SQL-запрос к СУБД, учитывая права доступа, разделители данных, итоги регистров и управляемые блокировки. Это удобно и безопасно, но добавляет слой абстракции, который иногда мешает увидеть реальную картину.
Понимание физической структуры нужно в трёх случаях: при анализе планов выполнения запросов, при ручной диагностике повреждённых данных и при построении прямых интеграций. Без этого знания администратор видит только «медленно работает 1С», а не конкретный запрос, который сканирует таблицу на миллионы записей.
Какие задачи решаются штатными средствами, а где нужен SQL
Проведение документов, расчёт итогов, построение отчётов, обмены по планам обмена, регламентные задания — всё это реализуется встроенным языком и языком запросов 1С. Лезть в СУБД напрямую для таких задач не нужно и вредно: платформа контролирует целостность, версионирование и блокировки, а прямое вмешательство эти гарантии обходит.
SQL становится необходим, когда задача находится вне компетенции платформы: обслуживание индексов и статистики, настройка резервного копирования средствами СУБД, анализ блокировок на уровне сервера, выгрузка данных для внешних систем, поиск «узких мест» через профилировщик СУБД. Это зона ответственности администратора баз данных, и здесь без SQL не обойтись.
Язык запросов 1С против прямого SQL
Подходит для всей логики внутри конфигурации: отчёты, обработки, проведение. Учитывает права и итоги, переносим между СУБД. Ограничение — нет доступа к служебным функциям СУБД.
Нужен для администрирования, диагностики и интеграций. Даёт полный контроль, но обходит права, блокировки и бизнес-логику платформы. Ошибка может разрушить данные.
Компромисс: 1С подключается к внешней SQL-базе и работает с ней через объектную модель. Подходит для чтения данных сторонних систем без ручного SQL.
Администрирование и обслуживание базы через SQL
Регулярное обслуживание клиент-серверной базы 1С выполняется средствами СУБД: перестроение и реорганизация индексов, обновление статистики, контроль роста журнала транзакций, настройка планов обслуживания. В Microsoft SQL Server это делается через Maintenance Plans или скрипты T-SQL, в PostgreSQL — через VACUUM, ANALYZE и планировщики вроде pg_cron.
Резервное копирование — ещё одна зона SQL. Выгрузка базы в файл dt через конфигуратор подходит для переноса и обновлений, но для ежедневного резервирования больших баз используют штатные механизмы СУБД: полные и разностные копии, копии журнала транзакций. Это быстрее, позволяет восстановить базу на произвольный момент времени и не требует монопольного доступа.
- 1Настройте автоматическое резервное копирование средствами СУБД и проверьте восстановление на тестовой копии.
- 2Добавьте регулярное обновление статистики и обслуживание индексов по расписанию в нерабочее время.
- 3Контролируйте размер журнала транзакций и модель восстановления базы.
- 4Раз в месяц сверяйте фактический размер базы и темпы роста с доступным дисковым пространством.
- 5Периодически проверяйте базу штатной процедурой тестирования и исправления в конфигураторе.
Отдельная задача — диагностика блокировок. Когда пользователи жалуются на «зависания», администратор смотрит активные сессии и цепочки блокировок через системные представления СУБД (например, sys.dm_tran_locks и sys.dm_exec_sessions в MS SQL Server). Понимание, какой запрос к какой таблице держит блокировку, позволяет найти виновника — конкретный документ, отчёт или обмен.
Диагностика производительности: где SQL незаменим
Запрос, написанный на встроенном языке 1С, платформа превращает в SQL, и именно этот SQL исполняется сервером. Если отчёт работает медленно, причина почти всегда видна в плане выполнения запроса: полное сканирование таблицы вместо поиска по индексу, неудачный порядок соединений, устаревшая статистика.
Инструменты вроде SQL Server Profiler, Extended Events или pg_stat_statements в PostgreSQL показывают реальные запросы, которые 1С отправляет в СУБД, с длительностью и числом чтений. Сопоставив тяжёлый запрос с текстом в конфигураторе, разработчик понимает, что переписать: добавить отбор, убрать соединение с виртуальной таблицей, перенести условие из секции «ИТОГИ» в параметры виртуальной таблицы.
Как отличить проблему запроса от проблемы сервера
Запрос выполняется за приемлемое время и использует индексы
Запрос читает миллионы строк при выборке нескольких записей — проблема в тексте запроса или индексах
Блокировки кратковременны и снимаются сразу после операции
Одна сессия держит блокировку минутами, очередь ожидания растёт
Диски справляются при пиковой нагрузке
Длительные очереди диска даже при оптимальных запросах — узкое место в железе
Типичная ситуация: отчёт по остаткам регистра накопления тормозит из-за отсутствия отбора по периоду в параметрах виртуальной таблицы. На уровне 1С это выглядит как «медленный отчёт», а на уровне SQL видно, что СУБД сканирует всю таблицу итогов. Без умения читать план запроса такую проблему находят методом тыка — долго и ненадёжно.
Интеграции и обмен данными через SQL
На практике 1С редко живёт в изоляции: рядом работают сайты, CRM, WMS, весовое и кассовое оборудование. Один из распространённых способов интеграции — обмен через промежуточные таблицы SQL: внешняя система пишет данные в таблицу-буфер, а 1С читает её регламентным заданием через внешний источник данных или COM/ADO-соединение.
Обратный сценарий — прямое чтение базы 1С внешними системами. Бухгалтерская аналитика в Power BI, выгрузка справочника товаров на сайт, отчётность для головного офиса — всё это часто делается SQL-запросами к копии базы или реплике. Здесь критично понимать структуру хранения: какая физическая таблица соответствует нужному справочнику, как хранятся ссылки, перечисления и составные типы.
При проектировании интеграции через SQL заранее решите три вопроса: кто отвечает за целостность данных, как обрабатываются ошибки и повторные загрузки, что произойдёт при обновлении конфигурации. Игнорирование этих вопросов приводит к рассинхронизации, которую потом разбирают вручную неделями.
Аварийные ситуации и прямое изменение данных
Самая рискованная область применения SQL в 1С — ручное изменение данных напрямую в таблицах. Такое бывает нужно, когда база повреждена и не открывается конфигуратором, когда ошибка в данных блокирует проведение документов, или когда требуется массовая правка, которую штатными средствами выполнить невозможно.
Главная опасность — потеря целостности. Платформа 1С хранит данные взаимосвязанно: документ ссылается на справочники, движения регистров привязаны к документу, итоги агрегируют движения. Прямой DELETE или UPDATE нарушает эти связи, и результат проявляется не сразу, а при закрытии периода или перепроведении — когда откатить изменения уже сложно.
Безопасная граница самостоятельной работы: чтение данных, диагностика, обслуживание индексов и статистики, резервное копирование. Всё, что связано с изменением данных в обход платформы, относится к зоне повышенного риска и требует копии базы, тестового прогона и понимания структуры конкретной конфигурации.
Как выстроить изучение SQL для работы с 1С
Начинать стоит не с синтаксиса SELECT, а с понимания архитектуры: как платформа отображает объекты конфигурации на таблицы, где лежат движения документов, как устроены итоги регистров. Для этого достаточно тестовой базы на PostgreSQL или SQL Server Express и нескольких запросов к системным представлениям.
Дальше — практика на безопасных задачах: трассировка запросов конкретного отчёта, чтение плана выполнения, поиск медленных запросов по статистике СУБД. Эти навыки сразу применимы в работе и не несут риска для данных. Прямые изменения данных осваивайте в последнюю очередь и только на копиях.
Как выбрать инструмент под задачу
Самый быстрый способ научиться видеть связь между 1С и SQL — включить трассировку на тестовом сервере, провести один документ и посмотреть, какие запросы платформа отправила в СУБД. Один такой эксперимент даёт больше понимания, чем чтение документации, потому что показывает реальную структуру таблиц вашей конфигурации.
Часто задаваемые вопросы
Можно ли обойтись без SQL, работая с 1С?
Для разработки внутри конфигурации — да: встроенного языка запросов достаточно для подавляющего большинства задач. SQL становится необходим при переходе к клиент-серверным базам в роли администратора: обслуживание, резервирование, диагностика производительности и блокировок выполняются средствами СУБД.
Какая СУБД лучше для 1С — SQL Server или PostgreSQL?
Обе поддерживаются платформой и применяются на практике. PostgreSQL привлекает отсутствием лицензионных платежей, Microsoft SQL Server — развитыми инструментами диагностики и администрирования. Выбор обычно определяется имеющейся инфраструктурой, квалификацией администраторов и бюджетом, а не принципиальной разницей в работе 1С.
Опасно ли читать данные из базы 1С напрямую через SQL?
Чтение само по себе безопасно для целостности данных, но имеет нюансы: структура физических таблиц недокументирована и может измениться при обновлении, а тяжёлые аналитические запросы способны нагрузить рабочую базу. Поэтому аналитику лучше строить по копии или реплике, а не по боевой базе.
Что делать, если после прямого изменения данных через SQL отчёты показывают неверные цифры?
Типичная причина — рассинхронизация движений и итогов регистров. Выполните в конфигураторе тестирование и исправление с пересчётом итогов, затем перепроведите затронутые документы. Если изменения были масштабными и копии до правки нет, восстановление может потребовать ручной сверки данных — это долгий процесс, поэтому резервная копия перед любыми прямыми правками обязательна.
Можно ли создавать свои таблицы и хранимые процедуры в базе 1С?
Технически возможно, и для интеграционных буферных таблиц это иногда делают, но есть риски: обновление конфигурации и реструктуризация могут конфликтовать с посторонними объектами, а поддержка такой базы усложняется. Безопаснее размещать собственные таблицы в отдельной базе на том же сервере и обращаться к ним через внешние источники данных.
С чего начать изучение SQL администратору 1С?
Разверните тестовую клиент-серверную базу, научитесь находить физические таблицы объектов конфигурации, освойте трассировку запросов и чтение планов выполнения. Затем — обслуживание: индексы, статистика, резервное копирование и восстановление. Все эксперименты проводите только на копиях и тестовых базах.
Что важно запомнить
SQL в 1С — это инструмент администрирования, диагностики и интеграции, а не замена встроенному языку запросов. Чтение и обслуживание базы через SQL безопасны и необходимы, прямое изменение данных — крайняя мера, допустимая только после резервного копирования и проверки на копии. Главный навык специалиста — видеть связь между объектами конфигурации и физическими таблицами СУБД.