Работа с данными 1С напрямую через SQL Server Management Studio (SSMS) — это мощный инструмент для разработчика и администратора, позволяющий анализировать структуру хранения, выполнять сложные выборки для отчетов или диагностировать проблемы производительности. Однако при первом знакомстве с базой данных 1С на SQL-сервере многие сталкиваются с трудностями: названия таблиц кажутся бессмысленными (например, _Document329), а вместо привычных ссылок видны непонятные двоичные данные. В этой статье мы подробно разберем, как расшифровать внутреннее устройство базы 1С и научиться эффективно работать с её таблицами.
Первое, с чем мы сталкиваемся — это «обфусцированные» имена таблиц. 1С не создает таблицы с именами «Справочник.Номенклатура», она использует внутренние идентификаторы. Чтобы понять, какая таблица SQL соответствует конкретному объекту метаданных, воспользуемся штатным методом платформы. Проанализируем способ получения этой структуры.
Для этого в контексте 1С (например, во внешней обработке) необходимо выполнить следующий код:
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Для Каждого СтрокаТаблицы Из СтруктураХранения Цикл
Сообщить("Объект 1С: " + СтрокаТаблицы.ИмяМетаданных + " -> Таблица SQL: " + СтрокаТаблицы.ИмяТаблицыХранения);
КонецЦикла;
Метод ПолучитьСтруктуруХраненияБазыДанных возвращает таблицу значений, в которой указаны соответствия имен объектов метаданных (справочники, документы, регистры) именам таблиц в СУБД. Параметр Истина позволяет получить детальную информацию, включая имена полей в этих таблицах.
Часто при просмотре таблиц через контекстное меню «Изменить первые 200 строк» (Edit Top 200 Rows) вместо идентификаторов мы видим заглушку «Двоичные данные». Выясним причину этого поведения. Интерфейс редактирования в SSMS — это упрощенный инструмент, который не предназначен для отображения сложных бинарных типов данных, таких как varbinary или binary(16).
Рассмотрим правильный способ просмотра: всегда используйте окно запросов (New Query) и оператор SELECT. Например:
SELECT TOP 100 * FROM _Reference25
В этом случае вместо надписи «Двоичные данные» вы увидите hex-представление (шестнадцатеричный код), начинающийся с 0x.... Именно в таком виде SQL Server хранит уникальные идентификаторы (GUID).
Одной из самых запутанных особенностей является разница в представлении GUID в 1С и в SQL Server. Если вы скопируете УникальныйИдентификатор из кода 1С и попробуете найти его в SQL простым сравнением, вы можете ничего не найти. Это происходит из-за специфического порядка байтов (так называемый Byte-Swapping).
Разберем алгоритм трансформации подробнее. GUID состоит из нескольких групп байтов. При записи в SQL 1С переставляет их местами. Посмотрим на схему:
Пример:
Если в SQL мы видим значение: 0x8AB50860 6E6E 87D7 ...
То в 1С это будет выглядеть как: 6008B58A-6E6E-D787-... (обратите внимание, как перевернулся первый блок 8AB50860 в 6008B58A).
Эту особенность критически важно учитывать при написании запросов JOIN или фильтров WHERE, если вы оперируете идентификаторами, полученными из интерфейса 1С.
Проанализируем еще одну странность: при просмотре колонки с датами (например, _Date_Time) вы можете увидеть значения вроде 4023-10-15 вместо ожидаемого 2023-10-15. Рассмотрим, почему это происходит.
1С по умолчанию добавляет 2000 лет к каждой дате при сохранении в SQL. Это техническое решение было принято для корректной обработки «пустых» дат (01.01.0001). Минимальная дата, которую поддерживает тип datetime в старых версиях SQL Server — 1753 год, поэтому 1С «сдвигает» весь диапазон времени в будущее.
Чтобы получить человекочитаемую дату в SQL-запросе, используйте функцию DATEADD:
SELECT DATEADD(year, -2000, _Date_Time) AS RealDate FROM _Document329
Если в конфигураторе 1С поле имеет составной тип (например, тип «ЛюбаяСсылка»), то в таблице SQL вместо одной колонки будет создано целое семейство полей с одинаковым номером, но разными суффиксами. Разберем их назначение:
_Fld123_TYPE — хранит код типа (например, 0x08 для справочников)._Fld123_RRef — хранит непосредственно двоичные данные самого GUID ссылки._Fld123_TRef — содержит идентификатор таблицы (чтобы система знала, в какой именно таблице искать объект с данным GUID)._Fld123_RRRef — используется для хранения значений простых типов (число, строка), если они входят в составной тип.Помимо ваших данных, каждая таблица 1С содержит технические поля, необходимые для работы платформы. Рассмотрим основные:
_IDRRef — первичный ключ (UID) текущей записи. По нему осуществляются все связи._Version — метка версии объекта (timestamp). SQL Server автоматически обновляет её при каждом изменении записи. Это нужно 1С для контроля объектной блокировки (чтобы два пользователя не перезаписали изменения друг друга)._Marked — булево поле, отвечающее за «Пометку на удаление»._PredefinedID — идентификатор предопределенного элемента.Важно помнить, что значения перечислений в SQL не хранятся в виде строк типа «Оплачено» или «КОтгрузке». В соответствующих полях таблиц документов или справочников хранится индекс — порядковый номер значения перечисления, заданный в конфигураторе (начиная с нуля). Чтобы расшифровать это значение в SQL-запросе, вам придется вручную сопоставлять цифры с порядком имен в дереве метаданных 1С.
Проанализируем основные правила безопасности и эффективности:
UPDATE или INSERT в обход платформы 1С крайне опасна. Это может нарушить ссылочную целостность, не обновит поле _Version или не затронет связанные регистры. Используйте SQL только для чтения и анализа.nvarchar(max) в SQL. Помните, что фильтрация и индексация по таким полям работают значительно медленнее, чем по полям ограниченной длины (nvarchar(N)).DBSchema, но она хранится в бинарном формате 1С, и для её чтения потребуются сторонние парсеры.Таким образом, мы выяснили, что структура 1С в SQL логична, хотя и требует понимания специфических механизмов трансформации байтов и смещения дат. Используя метод ПолучитьСтруктуруХраненияБазыДанных и понимая принципы хранения GUID, вы сможете проводить глубокий технический аудит любой базы данных 1С.