Многие аналитики и начинающие разработчики при получении доступа к SQL-серверу рабочей базы 1С сталкиваются с иллюзией простоты. Кажется, что достаточно написать несколько простых запросов с операторами JOIN, и все необходимые данные мгновенно окажутся в Excel или Power BI. Однако реальность преподносит неприятный сюрприз: структура базы данных состоит из тысяч таблиц со сложными техническими именами вроде _AccumRg20050 и полями типа _Fld20051. Попытки расшифровать эти данные вручную или с помощью сомнительных обработок часто приводят к неполным данным, ошибкам и нарушению работы всей системы.
В этой статье мы подробно разберем, как устроена структура таблиц 1С на сервере управления базами данных (СУБД), проанализируем основные риски прямого обращения к SQL-базе и рассмотрим безопасные, легальные альтернативы автоматизации отчетности, которые сберегут ваше время и избавят от технических сбоев.
Прежде чем приступать к написанию запросов на уровне СУБД, давайте выясним, с какими скрытыми техническими препятствиями и рисками сопряжен этот подход:
_AccumRg20050) генерируются платформой динамически. Если администратор выполнит выгрузку и загрузку базы через файл формата .dt или обновит конфигурацию 1С, эти индексы могут измениться. В результате все ваши тщательно написанные SQL-скрипты в один момент перестанут работать.binary(16). Более того, порядок байт в них перевернут относительно стандартного представления UUID в SQL Server. Соединять таблицы по таким полям крайне неудобно без специальных функций конвертации.SELECT к одной таблице будет недостаточно — придется писать громоздкие алгоритмы расчета, которые платформа 1С «под капотом» выполняет автоматически.Если перед вами все же стоит задача изучить структуру хранения данных, не нужно использовать неофициальные обработки из интернета, которые часто отображают нечитаемые символы. Платформа 1С имеет встроенный безопасный инструмент для получения схемы данных.
Для решения этой задачи воспользуемся программным методом ПолучитьСтруктуруХраненияБазыДанных(). Этот метод возвращает полную таблицу соответствий метаданных 1С (документов, справочников, регистров) и физических таблиц SQL.
Рассмотрим пример создания простейшего кода в 1С, который выгрузит всю структуру БД в удобном формате:
ВыборкаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
ТабличныйДок = Новый ТабличныйДокумент;
// Заполняем заголовки и выгружаем результат для анализа
Для Каждого СтрокаТаблицы Из ВыборкаСтруктуры Цикл
// Здесь пишется код выгрузки в файл Excel или текстовую таблицу
КонецЦикла;
Этот метод абсолютно безопасен, всегда возвращает актуальные имена таблиц и полей для вашей текущей конфигурации и позволяет быстро сориентироваться в схеме БД.
Если вам необходимо воспроизвести сложный отчет на уровне СУБД, отличным решением будет анализ запроса, который сама платформа генерирует и отправляет на SQL Server. Выяснить структуру запроса можно двумя способами:
logcfg.xml в каталоге установки платформы и настройте сбор событий работы с СУБД.Пример настройки файла logcfg.xml для фиксации SQL-запросов к СУБД MS SQL:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8_logs" history="2">
<event>
<eq property="Name" value="DBMSSQL"/>
</event>
<property name="all"/>
</log>
</config>
Проанализировав полученный лог, мы сможем увидеть структуру связей таблиц, которую платформа использует для построения отчета. Однако помните, что автоматически сгенерированные запросы перегружены техническими конструкциями и временными таблицами, поэтому использовать их напрямую для BI-систем без глубокой переработки крайне затруднительно.
Для решения задачи ежедневного обновления аналитики (например, выгрузки 14 отчетов к 6 часам утра) оптимальным и самым простым решением является использование типового функционала 1С — Рассылка отчетов. Этот механизм работает полностью в автоматическом режиме на стороне сервера и не требует написания SQL-запросов.
Выполним настройку по шагам:
Этот способ полностью решает проблему обновления данных: утром вы приходите на работу, файлы в сетевой папке уже обновлены сервером 1С по расписанию, а ваш Power BI автоматически подтягивает свежие данные при обновлении модели.
Если вам требуется настроить прямое подключение BI-системы к базе данных без промежуточных файлов в папках, воспользуйтесь штатным механизмом платформы — автоматическим REST-сервисом по протоколу OData. Это современный, полностью легальный и безопасный инструмент.
Разберем алгоритм работы с OData:
http://имя_сервера/имя_публикации/odata/standard.odata/
Справочник_Номенклатура вместо непонятных SQL-префиксов).Использование OData позволяет полностью обойти проблемы со сдвигом дат, дешифровкой UUID и изменением индексов таблиц при обновлениях конфигурации. Все преобразования платформа берет на себя.
Если объемы данных исчисляются миллионами строк, а OData работает недостаточно быстро, вы можете использовать гибридный подход — обращение к СУБД через SQL-представления (Views) на копии базы данных.
Для реализации этого сценария выполните следующие действия:
CREATE VIEW v_Номенклатура AS
SELECT
_IDRRef AS Ссылка_ID,
_Description AS Наименование,
_Code AS Код
FROM _Reference131 -- Здесь указывается текущая физическая таблица 1С
_Reference145, вам достаточно будет переписать один этот View, а сам отчет в Power BI, подключенный к v_Номенклатура, продолжит работать без изменений.Проанализировав все варианты, мы видим, что прямой разбор SQL-таблиц «в лоб» — это наиболее трудоемкий метод, требующий постоянной поддержки работоспособности запросов. Использование штатной автоматической рассылки отчетов в папку или подключение по OData позволит вам решить задачу интеграции гораздо быстрее, надежнее и безопаснее.