Сегодня разбирал структуру данных 1С. Меня интересовало следующее:
- foreign keys в таблицах (в особенности, как реализованы реквизиты типа «неопределенный» или «документ»)
- «периодические реквизиты» в справочниках
- группы в справочниках (создается ли отдельная таблица для элементов групп?)
Я использовал dbview для просмотра DBF. В чистой новой базе я создаю справочник без реквизитов. Появляется файл SC12.DBF. Второй справочник – файл SC14.DBF. При этом в файл 1SUIDCTL.DBF добавляются записи для каждого справочника (поля Typeid / Maxid)
Добавляем ссылку (реквизит типа «справочник 2″) из первого справочника во второй. Это добавляет поле Sp16 в таблицу справочника (SC12.DBF). В таблице справочника два поля, id и code, тип строка. Второе поле выводится на экран как код элемента, который может быть изменен. Ключ записи – это immutable column ‘id’.
Реквизит «неопределенный»
Добавляем реквизит «Справочник» (неопределенный) в справочник 1. В файле SC12.DBF появляется поле SP17. После внесения записей, кое что проясняется: поле SP17 длинной в 13 байтов содержит в 1 байте ссылку на таблицу, а в 7-м – id (ключ) записи в этой таблице. Таблицы кодируются буквенными символами. Такие же символы в записях таблицы 1SUIDCTL.DBF
Группа в справочнике.
Увеличиваем кол-во уровней с 1 до 2. Появляется реквизиты Paretnid и Isfolder в SC12.DBF. Как и следовало ожидать, Parentid это ссылка на Id. Isfolder для группы имеет код 1, для элемента – 2.
Периодические реквизиты
Добавляем в справочник 2 периодический реквизит. Следующие изменения:
- 1SCONST.DBF: после добавления значений в переменный реквизит второго справочника, мы получаем эти значения в файле 1SCONST.DBF. Кроме даты мы видим реквизит Id, Objid (по всей видимости составной ключ, первое – ссылка на колонку таблицы [changed 17 jul 09], NOTE A, второе – ключ в этой таблице. По отдельности каждое поле не уникально ) и Value, собственно со значением. В самом же файле SC14.DBF (с таблицей второго справочника) никаких изменений. Т.е. периодические реквизиты – это виртуальные колонки в таблице. На самом деле их там нет. Нет соответственно и foreign keys. Значит значения таких реквизитов система находит исключительно по индексам 1SCONST.DBF где есть ссылки на «основной» справочник.
Все периодические значения хранятся в этой таблице (1SCONST.DBF). Я создал в первом справочнике реквизит «периодический», и после добавления значения оно появилось в том же 1SCONST.DBF (см выше о составном ключе). По всей видимости где-то хранятся таблицы соответствия таблицы/поля с кодом, который помещается при записи в таблицу периодических значений в поле Id. Тип данных для периодических реквизитов – строка.
Подчиненный справочник
Создаем третий справочник и «подчиняем» его первому. В итоге получаем:
Новый файл SC29.DBF c одной из колонок Parentext (для внутреннего подчинения используется поле Parentid). Parentext содержит ссылку на id записи в таблице – «владельце». Кода самой таблицы-владельца в записях таблицы подчиненного справочника нет.
Новая запись в 1SUIDCTL.DBF
Иные наблюдения.
Добавление общего реквизита в документы не изменяет timestamp ни одного DBF файла в базе.
Вероятно все параметры (=user defined columns) имеют уникальное кодовое имя типа Sp[No], где No – уникальный ключ
Добавление документа (конфигуратор) новые файлы:
1SJOURN.DBF
DH21.DBF
DT21.DBF
После добавления документа обновился кроме прочих файл 1SUIDCTL.DBF
Таблица DH21.DBF содержит Iddoc (ключ), и user defined атрибуты (Sp22 и Sp20 в моем случае). Таблица DT21.DBF – Iddoc (foreign key), Lineno (индекс) и опять же атрибут мною определенный в конфигураторе (Sp23)
Создаем еще один тип документа и новый журнал документов. Выясняем следующее: записи всех журналов хранятся в одной таблице 1SJOURN.DBF. Идентификатор журнала – поле Idjournal (0 для общего, O – для вновь созданного). В таблице есть поле Dnprefix, значение которого совпадает с числовой составляющей в названии файла таблиц, хранящих соответствующий документ. Так, для первого моего документа запись в журнале в этом поле имела значение 21. Осталось непонятным, где хранятся значения общих реквизитов.
БУХГАЛТЕРИЯ
Добавляем план счетов, определяем справочник валют. Новые файлы:
1SACCSEL.DBF
1SENTRY.DBF
1SOPER.DBF
1SSBSEL.DBF
1STOPER.DBF
1SACCS.DBF
1SBKTTLC.DBF
1SBKTTL.DBF
1SCORENT.DBF
DH33.DBF
Далее анализировать содержимое шибко не стал по разным причинам. На беглый взгляд, нормализация данных в этих таблицах довольно слабенькая.
Регистры учета (оперативный учет)
Две таблицы для каждого регистра – движения и итоги. В таблице движений – поля для измерений, ресурсов и атрибутов. В таблице итогов атрибуты отсутствуют. Все очень просто и предсказуемо.
NOTE A: Очевидно каждая колонка (или атрибут того или иного объекта, в терминологии 1С), получает свой внутренний id. Далее этот id используется для foreign keys.



26 Август, 2009 в 9:47 пп |
Спасибо за исследования:)
А это про какую версию платформы идет речь – 7.7 или 8? И актуальна ли такая же структура таблиц для серверного варианта (на MS SQL, например)?
26 Август, 2009 в 10:18 пп |
я смотрел 7.7 версию. sql инсталляцию я не проверял, сказать ничего не могу.