Чем отличается 1С на SQL: файловый режим, выбор СУБД и особенности запросов

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

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

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

Архитектура: в чём принципиальное отличие файлового и SQL-режима

В файловом режиме вся база — это один файл 1Cv8.1CD на диске или сетевом ресурсе. Каждый пользовательский сеанс читает и пишет в этот файл напрямую, а блокировки ставятся на уровне всей таблицы. Пока один пользователь проводит документ, остальные ждут. При активной работе более 5–10 пользователей очереди из блокировок становятся заметны невооружённым глазом.

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

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

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

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

Из этого вытекают ограничения, которых нет в классическом SQL. В языке запросов 1С нельзя выполнять DDL-операции (создание и изменение таблиц), нельзя напрямую изменять данные — запросы только читают, изменение идёт через объектную модель. Нет и произвольных хранимых процедур: бизнес-логика живёт в модулях конфигурации, а не в базе.

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

Сравнение режимов: производительность, блокировки, надёжность

Различия удобнее всего видны в сопоставлении ключевых характеристик обоих режимов:

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

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

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

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

Клиент-серверный на MS SQL Server

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

Клиент-серверный на PostgreSQL

Снижает стоимость СУБД, есть адаптированные сборки для 1С. Ограничение: требует отдельной настройки и опыта администрирования PostgreSQL.

IBM DB2 / Oracle

Встречаются в крупных организациях с существующей инфраструктурой этих вендоров. Ограничение: меньше специалистов и готовых практик именно под 1С.

Отличия между СУБД для 1С: MS SQL, PostgreSQL и другие

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

Microsoft SQL Server — самый распространённый выбор. Для него больше всего накоплено практик: типовые настройки (например, отдельные диски под tempdb и журналы), инструменты диагностики блокировок, готовые скрипты обслуживания. Минус — лицензионная стоимость, которая при большом числе ядер становится существенной статьёй бюджета.

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

IBM DB2 и Oracle применяются реже, как правило там, где они уже есть в ИТ-ландшафте организации. Для них сложнее найти специалистов именно в связке с 1С, а тонкости настройки приходится искать в документации вендора и редких отраслевых материалах.

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

Когда файлового режима достаточно, а когда нужен SQL

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

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

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

Как выбрать действие

Одновременно работают до 5–10 пользователей, жалоб на блокировки нетОставайтесь на файловом режиме, следите за размером базы и делайте регулярные копии

Пользователи жалуются на ошибки «Конфликт блокировок» и ожидания при проведенииПланируйте переход на клиент-серверный режим

Требуется работа 30+ пользователей или круглосуточный режимКлиент-серверный режим обязателен, закладывайте отказоустойчивость СУБД

Бюджет ограничен, но серверный режим нуженРассмотрите PostgreSQL с адаптированной сборкой и привлечением администратора

Переход с файловой базы на SQL: порядок действий и риски

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

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

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

Частые ошибки и как проверить результат

Большинство проблем после перехода связано не с 1С, а с настройкой СУБД. Типовые ошибки повторяются от проекта к проекту.

После перехода и в ходе эксплуатации полезно периодически проверять состояние системы по контрольным точкам.

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

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

Проведение типового документа в часы пик

Норма

Выполняется за привычное время, ошибок блокировок нет

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

Регулярные «Конфликт блокировок при выполнении транзакции»

Скорость ключевых отчётов

Норма

Время сопоставимо с файловой базой или лучше

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

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

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

Норма

Бэкап средствами СУБД выполняется по расписанию и тестово восстанавливается

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

Копии нет или восстановление никогда не проверялось

Сверка итогов после перехода

Норма

ОСВ и остатки по регистрам совпадают с файловой базой

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

Есть расхождения — переход нужно повторить с разбором причин

FAQ: частые вопросы о 1С и SQL

Можно ли писать обычные SQL-запросы внутри кода 1С?

Нет, встроенный язык работает только с языком запросов 1С. Платформа сама транслирует его в диалект целевой СУБД. Обойти это можно только через внешние компоненты или COM/ADO-подключения к другим базам, но к собственной базе 1С так обращаться не следует.

Нужно ли менять конфигурацию при переходе с файлового режима на SQL?

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

Что дешевле для небольшой компании: MS SQL или PostgreSQL?

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

Почему после перехода на SQL отчёты стали медленнее?

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

Можно ли вернуться с SQL-режима обратно на файловый?

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

Отличается ли резервное копирование в SQL-режиме?

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