Разработка и Конфигурация · 11 мин
Какой SQL нужен для 1С и что учить в первую очередь
Разбираем, какой SQL нужен для работы с 1С: чем язык запросов 1С отличается от классического SQL, какие СУБД поддерживаются и что учить в первую очередь.
Разработчику и администратору 1С нужны два разных пласта знаний: встроенный язык запросов 1С, которым пишутся выборки внутри конфигурации, и основы классического SQL, которые применяются при работе с СУБД — Microsoft SQL Server, PostgreSQL, Oracle или IBM Db2. Путать их нельзя: запросы внутри 1С пишутся на собственном диалекте платформы, а «чистый» SQL нужен лишь для обслуживания базы, диагностики и интеграций.
Для большинства задач — отчёты, обработки, доработка конфигураций — достаточно языка запросов 1С. Он похож на SQL синтаксически, но работает с объектами метаданных (справочниками, документами, регистрами), а не с физическими таблицами. Прямые запросы к таблицам СУБД в обход платформы — редкий и рискованный приём, оправданный только для чтения данных или административных операций.
Ниже разберём, какие именно знания SQL нужны под разные роли, чем диалект 1С отличается от стандартного SQL, какие СУБД поддерживает платформа и где проходит граница безопасной самостоятельной работы с базой.
Какие «SQL» вообще существуют в экосистеме 1С
Под словом «SQL» в контексте 1С обычно скрываются три разные вещи. Первая — язык запросов 1С, встроенный в платформу: им пользуются все разработчики при написании отчётов, обработок, динамических списков и заполнении СКД. Вторая — диалект SQL конкретной СУБД, на которой развёрнута клиент-серверная база: T-SQL для Microsoft SQL Server, PL/pgSQL для PostgreSQL. Третья — SQL для внешних источников данных, когда 1С подключается к сторонней базе через ODBC и читает или пишет туда данные.
Файловый вариант базы (файл 1Cv8.1CD) вообще не использует SQL в привычном смысле: платформа сама хранит и читает данные. Поэтому требование «знать SQL» в вакансиях 1С чаще всего означает владение языком запросов платформы, а не администрирование СУБД.
Язык запросов 1С: обязательный минимум разработчика
Базовый набор конструкций, без которых невозможна разработка: ВЫБРАТЬ с полями и псевдонимами, соединения таблиц (ЛЕВОЕ, ВНУТРЕННЕЕ СОЕДИНЕНИЕ), условия ГДЕ, группировки с агрегатными функциями (СУММА, КОЛИЧЕСТВО, МАКСИМУМ), упорядочивание и итоги. Следующий уровень — виртуальные таблицы регистров (Остатки, Обороты, СрезПоследних), параметризованные запросы, временные таблицы и пакетные запросы.
Отдельно стоит освоить конструкции, специфичные для 1С: РАЗРЕШЕННЫЕ для учёта прав доступа, оператор В для проверки вхождения в список или иерархию (В ИЕРАРХИИ), ВЫРАЗИТЬ для приведения типов составных полей, РАЗНОСТЬДАТ и функции работы с датами. Именно эти возможности отличают грамотный запрос от «переведённого с SQL» и напрямую влияют на производительность.
Пример типового запроса к виртуальной таблице остатков:
ВЫБРАТЬ
Остатки.Номенклатура КАК Номенклатура,
Остатки.КоличествоОстаток КАК Остаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Склад = &Склад) КАК Остатки
ГДЕ
Остатки.КоличествоОстаток > 0
Проверить результат проще всего в консоли запросов: выполняете запрос с реальными параметрами и сверяете итоги с данными стандартного отчёта конфигурации. Расхождение — признак ошибки в отборах или периоде виртуальной таблицы.
- 1Изучите базовый синтаксис: ВЫБРАТЬ, ГДЕ, СОЕДИНЕНИЕ, СГРУППИРОВАТЬ ПО
- 2Потренируйтесь на виртуальных таблицах регистров: Остатки, Обороты, СрезПоследних
- 3Освойте временные таблицы и пакетные запросы для сложных выборок
- 4Отрабатывайте запросы в консоли запросов на копии рабочей базы
- 5Проверяйте результат сверкой с типовым отчётом конфигурации
Классический SQL: когда он действительно нужен
Знание «настоящего» SQL требуется в трёх сценариях. Первый — администрирование клиент-серверной базы: создание бэкапов средствами СУБД, настройка планов обслуживания, перестроение индексов, анализ блокировок через системные представления. Второй — диагностика производительности: чтение планов запросов, поиск тяжёлых операторов, которые платформа сгенерировала из запроса 1С. Третий — интеграции: выгрузка данных из 1С во внешние системы или чтение сторонних баз через внешние источники данных.
Для этих задач достаточно уверенного владения SELECT с соединениями и подзапросами, понимания индексов и планов выполнения, а также административных команд конкретной СУБД. Писать хранимые процедуры и триггеры в базе 1С не требуется — более того, это запрещено лицензионными условиями и ломает обновление конфигурации.
Какие СУБД поддерживает 1С и какой диалект учить
Платформа 1С:Предприятие 8 работает с четырьмя СУБД: Microsoft SQL Server, PostgreSQL (включая сборки, адаптированные под 1С), Oracle Database и IBM Db2. На практике подавляющее большинство внедрений — это MS SQL Server и PostgreSQL, поэтому учить стоит один из этих двух диалектов.
Выбор СУБД для 1С
Самый распространённый вариант для средних и крупных баз. Удобные инструменты диагностики (Management Studio, профилировщик). Ограничение — стоимость лицензий.
Бесплатная альтернатива, есть сборки с патчами под 1С. Требует более внимательной настройки конфигурации сервера под нагрузку 1С.
Встречаются в крупных организациях с существующей инфраструктурой. Осваивать имеет смысл только под конкретное место работы.
Если вы администратор, выбирайте диалект той СУБД, которая уже развёрнута в организации: синтаксис выборок похож, но административные команды, системные представления и механизмы бэкапа у каждой СУБД свои. Переносить приёмы из T-SQL в PostgreSQL без проверки нельзя — например, подходы к обслуживанию индексов и сбору статистики различаются принципиально.
Чем язык запросов 1С отличается от SQL и частые ошибки
Главное отличие — уровень абстракции. Запрос 1С обращается к «Справочник.Номенклатура» или «РегистрНакопления.Продажи.Обороты», а платформа сама решает, из каких физических таблиц собрать результат. Из этого следуют практические последствия: нельзя узнать имена физических таблиц без специальной обработки, нельзя использовать функции конкретной СУБД внутри запроса 1С, а оптимизировать запрос нужно средствами платформы — правильным выбором виртуальных таблиц, параметров и индексирования реквизитов.
Ещё одна распространённая ошибка — игнорировать конструкцию РАЗРЕШЕННЫЕ в запросах, которые выполняются под пользователями с ограниченными правами. Без неё пользователь может увидеть данные, к которым у него нет доступа, или наоборот — получить ошибку при выполнении отчёта.
SQL для интеграций и внешних источников данных
Когда 1С должна читать или писать данные во внешнюю систему — сайт, CRM, складскую программу — используются внешние источники данных через ODBC или обмен через COM/веб-сервисы. Вот здесь классический SQL нужен в полной мере: вы пишете запросы к чужой базе в её диалекте, и ответственность за корректность лежит на вас, а не на платформе.
Практические правила для таких сценариев: из внешней базы читайте только нужные поля с явными отборами, а не «звёздочкой»; запись во внешнюю систему делайте через параметризованные запросы, чтобы избежать SQL-инъекций и ошибок типов; обязательно тестируйте обмен на копии, потому что ошибка во внешней базе не откатывается механизмами 1С.
Как проверить, что знаний достаточно для вашей роли
Ориентируйтесь на задачи, которые вы реально решаете. Разработчику достаточно уверенно писать пакетные запросы с временными таблицами, читать результат СКД и понимать, почему запрос тормозит. Администратору добавляется умение снять план запроса в СУБД, найти блокировку и настроить регламентное обслуживание. Интегратору — свободный SQL в диалекте целевой системы.
Что учить под вашу задачу
Как проверить уровень владения
Запрос пишется без подсказок и возвращает корректные итоги
Путаетесь в параметрах виртуальных таблиц — повторите эту тему
Умеете посмотреть план запроса и найти сканирование таблицы
Единственный метод оптимизации — перезапуск сервера
Чётко понимаете: в базу 1С только чтение, запись — через платформу
Рассматриваете прямые UPDATE к таблицам как рабочий приём
Что важно запомнить
Основной «SQL для 1С» — это встроенный язык запросов платформы, его обязан знать каждый разработчик. Классический SQL нужен администраторам для обслуживания СУБД и интеграторам для обменов, причём в диалекте конкретной СУБД. Прямая запись в таблицы базы 1С запрещена всегда и в любых условиях.
Частые вопросы
Можно ли работать с 1С, совсем не зная SQL?
Для пользователя и настройщика типовых отчётов — да. Для разработчика — нет: язык запросов 1С входит в базовый набор навыков, без него невозможно написать ни один нестандартный отчёт или обработку. Классический SQL при этом можно осваивать позже, по мере перехода к клиент-серверным задачам.
Что учить первым: язык запросов 1С или классический SQL?
Язык запросов 1С — он нужен ежедневно и проще входит в работу, потому что оперирует понятными объектами конфигурации. Знание классического SQL помогает понять логику соединений и группировок, но не является предварительным условием: многие разработчики 1С успешно начинают без него.
Какая СУБД лучше для изучения под 1С — MS SQL Server или PostgreSQL?
Выбирайте ту, что используется в вашей организации или на целевом рынке вакансий. MS SQL Server чаще встречается в коммерческих внедрениях и имеет более дружелюбные инструменты диагностики. PostgreSQL выбирают ради экономии на лицензиях, но он требует аккуратной настройки под нагрузку 1С.
Можно ли подключиться к базе 1С из Excel или Power BI напрямую по SQL?
Технически чтение из таблиц СУБД возможно, но структура таблиц недокументирована и может меняться при обновлениях платформы. Правильный путь — опубликовать данные через веб-сервисы, OData-интерфейс платформы или регламентные выгрузки. Так вы получаете стабильный и поддерживаемый канал обмена.
Почему запрос, который быстро работает в консоли SQL, медленный внутри 1С?
Потому что платформа генерирует собственный SQL из запроса 1С, добавляя проверки прав, соединения с таблицами типов и служебные поля. Оптимизировать нужно не «ручной» SQL, а сам запрос 1С: задавать параметры виртуальных таблиц, убирать функции из условий соединений и проверять индексацию реквизитов, по которым идёт отбор.
Нужен ли SQL для файловой версии 1С?
Нет, файловый вариант хранит данные в собственном формате, и никакая СУБД не участвует в работе. Достаточно языка запросов платформы. Классический SQL понадобится только при переходе на клиент-серверный вариант или при интеграциях с внешними базами.