Что такое «скул» в 1С и зачем он нужен

«Скул» — это разговорное произношение аббревиатуры SQL (Structured Query Language, язык структурированных запросов). В контексте 1С под «скулом» обычно понимают не сам язык, а сервер баз данных — Microsoft SQL Server, PostgreSQL, Oracle или IBM DB2, — на котором хранится информационная база. Когда администратор говорит «база лежит на скуле», он имеет в виду, что 1С работает в клиент-серверном режиме и все данные физически размещены в СУБД.

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

Понимание того, что такое «скул» в 1С, важно администраторам, внедренцам и руководителям: от этого зависят выбор режима работы базы, требования к серверу, порядок резервного копирования и границы безопасных действий с данными.

Что скрывается за словом «скул» в разговорах про 1С

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

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

Файловый и клиент-серверный режимы: в чём разница

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

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

Сравнение вариантов

Файловый режим

Подходит для небольших команд и баз умеренного размера. Ограничение: чувствителен к обрывам сети и одновременной работе большого числа пользователей.

Клиент-серверный режим (SQL)

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

Как 1С использует SQL изнутри

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

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

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

Когда бизнесу нужен переход на SQL-версию

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

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

1. 1
   Сделайте резервную копию файловой базы и проверьте её целостность через конфигуратор
2. 2
   Установите и настройте СУБД и сервер 1С:Предприятия, создайте пустую базу в кластере
3. 3
   Выгрузите исходную базу в файл .dt и загрузите её в новую серверную базу
4. 4
   Проверьте открытие базы в пользовательском режиме, работу отчётов и регламентных заданий
5. 5
   Переведите пользователей на новое подключение и заблокируйте старую файловую базу

Резервное копирование и обслуживание SQL-базы

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

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

Типичные ошибки и заблуждения про «скул» в 1С

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

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

Как проверить, что всё работает правильно

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

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

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

Открытие базы пользователями

Норма

Вход выполняется без ошибок, сеансы видны в консоли сервера 1С

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

Ошибки соединения с СУБД или зависание при входе

Резервное копирование

Норма

Копии создаются по расписанию и тестово восстанавливаются

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

Копий нет, или восстановление ни разу не проверялось

Скорость работы

Норма

Типовые операции выполняются без заметных пауз

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

Постоянные блокировки и таймауты в журнале регистрации

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

«Скул» и «SQL» — это одно и то же?

Да. «Скул» — просто разговорное произношение аббревиатуры SQL. В среде специалистов 1С так чаще всего называют сам сервер баз данных, например Microsoft SQL Server.

Нужно ли учить SQL, чтобы программировать в 1С?

Не обязательно. Прикладная разработка ведётся на встроенном языке запросов 1С, который платформа сама переводит в SQL. Знание SQL полезно администраторам и при диагностике производительности, но не является входным требованием для разработчика.

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

Чаще всего выбирают между Microsoft SQL Server и PostgreSQL. MS SQL проще в администрировании для типовых внедрений, но требует лицензий; PostgreSQL бесплатен, но требует более внимательной настройки. Выбор зависит от бюджета, компетенций администраторов и требований к нагрузке.

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

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

Что надёжнее: выгрузка .dt или бэкап средствами СУБД?

Они решают разные задачи. Копия СУБД быстрее восстанавливается и позволяет откатиться на момент времени, а .dt универсален и переносит базу между разными СУБД и режимами. Рекомендуется сочетать оба способа.

Когда файловой базы уже недостаточно?

Тревожные признаки: рост числа одновременных пользователей, заметное замедление работы, ошибки при параллельном проведении документов, длительное закрытие периода и требования к бесперебойной работе. При их появлении стоит планировать переход на клиент-серверный режим.