Содержание:

1. Автоматизация управления структурой таблиц и колонок в 1С: Предприятие

2. Общие принципы именования и типы колонок в системе программы 1С: Предприятие

3. Специфика для разных объектов метаданных 1С

4. Почему важно понимать структуру колонок

Система программы 1С: Предприятие предоставляет разработчикам и пользователям высокоуровневый интерфейс для работы с данными через объекты метаданных: справочники, документы, регистры и так далее. Мы оперируем понятиями “Реквизит”, “Измерение”, “Ресурс”. Однако на физическом уровне, в реляционной базе данных (СУБД), с которой работает платформа 1С (будь то MS SQL Server, PostgreSQL, Oracle Database или другая поддерживаемая СУБД), все эти сущности трансформируются в таблицы, а их атрибуты – в колонки (столбцы) этих таблиц. Понимание того, как метаданные 1С проецируются на структуру колонок СУБД, критически важно для оптимизации запросов, анализа производительности, интеграции с другими системами на уровне данных и глубокого траблшутинга.

Автоматизация управления структурой таблиц и колонок в 1С: Предприятие

Платформа системы 1С: Предприятие берет на себя всю работу по созданию и управлению структурой таблиц и колонок в СУБД.

Разработчик в Конфигураторе определяет, например, справочник “Контрагенты” с реквизитами “Наименование” (строка), “ИНН” (строка), “ГоловнойКонтрагент” (ссылка на этот же справочник).

Платформа же, при реструктуризации базы данных, создаст в СУБД таблицу (например, _Reference123, где 123 – внутренний идентификатор объекта метаданных “СправочникКонтрагенты”) и соответствующие колонки для хранения этих данных.

Общие принципы именования и типы колонок в системе программы 1С: Предприятие

1. Системные колонки: Каждая основная таблица объекта 1С (справочника, документа, бизнес-процесса, задачи и т.д.) содержит ряд служебных колонок, генерируемых платформой:

• _IDRRef (Identity Record Reference): Уникальный идентификатор записи (объекта), обычно типа BINARY(16) (для хранения GUID). Это первичный ключ таблицы.
• _Version: Версия строки (timestamp или rowversion в MS SQL), используется для механизма оптимистической блокировки.
• _Marked: Пометка на удаление (BINARY(1) или BIT, 0 или 1).
• _IsFolder: Для справочников, указывающий, является ли элемент группой (BINARY(1) или BIT).
• _ParentIDRRef: Для иерархических справочников, ссылка на _IDRRef родительского элемента.
• _PredefinedID: Идентификатор предопределенного элемента (если есть).

2. Колонки для реквизитов, измерений, ресурсов:

• Простые типы:
• Строка (String): Транслируется в NVARCHAR(N) или VARCHAR(N) в MS SQL, VARCHAR(N) в PostgreSQL. N определяется длиной строки, заданной в метаданных. Неограниченная строка может транслироваться в NVARCHAR(MAX) или TEXT.
• Число (Number): NUMERIC(P,S) или DECIMAL(P,S), где P – точность, S – масштаб. Для целых чисел может быть INT, BIGINT и т.д.
• Дата (Date): DATETIME2(S) в MS SQL, TIMESTAMP(S) в PostgreSQL. Компонента времени может отсутствовать в зависимости от состава даты в метаданных 1С.
• Булево (Boolean): BIT в MS SQL, BOOLEAN в PostgreSQL.
• Ссылка (Reference) на другой объект: BINARY(16) (для хранения GUID объекта, на который идет ссылка).
• Перечисление (Enum): Обычно BINARY(16) для ссылки на экземпляр перечисления (_EnumXXX), либо иногда может использоваться числовой идентификатор порядка значения (_EnumOrder). Платформа генерирует для каждого перечисления таблицу вида _EnumXXX со столбцами _IDRRef и _EnumOrder.
• ХранилищеЗначения (ValueStorage): Транслируется в тип данных для хранения больших двоичных объектов (BLOB), например IMAGE или VARBINARY(MAX) в MS SQL, BYTEA в PostgreSQL.
• Именование пользовательских колонок: Обычно к имени реквизита, заданному в конфигураторе, добавляется префикс _Fld и числовой идентификатор поля. Например, реквизит “ИНН” справочника “Контрагенты” может превратиться в колонку _Fld456 в таблице _Reference123. Увидеть соответствие имен можно, например, через выгрузку конфигурации в XML-файлы или с помощью специализированных инструментов.

3. Составные типы данных:

Если реквизит имеет составной тип данных (например, может хранить ссылку на “Контрагента” или “ФизическоеЛицо”), то для него в таблице СУБД создаются несколько колонок:

• _FldXYZ_TYPE (BINARY(1)): Байт, указывающий на тип активной ссылки (0 – пустая ссылка, 1 – первый тип из списка составного типа, 2 – второй тип и т.д.).
• _FldXYZ_RTRef (BINARY(4)): Идентификатор типа объекта из таблицы _TPRTRefs (или аналогичной системной).
• _FldXYZ_RRRef (BINARY(16)): Сама ссылка (GUID) на объект, если активный тип – ссылочный. Для примитивных типов значение может быть в отдельной колонке с соответствующим типом.

Специфика для разных объектов метаданных 1С

• Документы (_DocumentXXX):
  • _Date_Time: Дата документа (тип DATETIME2 или TIMESTAMP).
  • _Number: Номер документа (строковый или числовой, в зависимости от настроек нумератора).
  • _Posted: Признак проведения документа (BINARY(1) или BIT).
  • Колонки для реквизитов шапки документа.
• Табличные части (_DocumentXXX_VT_YYY, _ReferenceXXX_VT_YYY):
  Хранятся в отдельных таблицах. YYY – идентификатор табличной части.
  • _DocumentXXX_IDRRef или _ReferenceXXX_IDRRef: Ссылка на _IDRRef объекта-владельца (документа или элемента справочника).
  • _KeyField: Уникальный ключ строки в пределах табличной части (обычно INT).
  • _LineNo: Номер строки, видимый пользователю.
  • Колонки для реквизитов табличной части.
• Регистры сведений (_InfoRgXXX):
  • _Period (для периодических регистров): Дата записи (DATETIME2 или TIMESTAMP).
  • Колонки для измерений (по ним строится первичный ключ или уникальный индекс).
  • Колонки для ресурсов.
  • _RecorderTRef и _RecorderRRef (для регистров, подчиненных регистратору): Тип и ссылка на документ-регистратор.
  • _Active (для периодических регистров с режимом записи “Замещение”): Признак активности записи.
• Регистры накопления (_AccumRgXXX):
  • _Period: Период записи (момент времени).
  • _RecorderTRef и _RecorderRRef: Тип и ссылка на документ-регистратор.
  • _LineNo: Номер строки записи в наборе записей регистратора.
  • _Active: Признак активности записи (используется при отмене проведения документа).
  • _RecordKind: Вид движения (0 – приход, 1 – расход).
  • Колонки для измерений.
  • Колонки для ресурсов.

Почему важно понимать структуру колонок

1. Прямые SQL-запросы: Хотя 1С предоставляет свой язык запросов, иногда для сложных отчетов, аналитики или интеграции с BI-системами требуются прямые SQL-запросы к базе данных. Знание имен таблиц и колонок, а также их типов, здесь абсолютно необходимо.
2. Анализ производительности: При анализе планов выполнения SQL-запросов (сгенерированных платформой 1С или написанных вручную) нужно понимать, к каким колонкам идет обращение, есть ли по ним индексы, каковы их типы данных (для оценки селективности, возможности неявных преобразований и т.д.).
3. Интеграция: При обмене данными с другими системами на уровне СУБД понимание структуры помогает корректно настроить маппинг полей.
4. Диагностика проблем: В редких случаях, при повреждении данных или сложных ошибках, анализ данных непосредственно в таблицах СУБД может помочь локализовать проблему.
5. Оптимизация конфигурации: Понимание того, как выбор типов данных в метаданных (например, длина строки, точность числа, использование составных типов) влияет на физическую структуру, может помочь в проектировании более оптимальных конфигураций.

Осторожность при работе с физической структурой!

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

Доступ к данным СУБД на уровне SQL-запросов должен быть преимущественно только для чтения (SELECT) и с полным пониманием рисков.

Заключение:

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

Специалист компании ООО “Кодерлайн”,

Радченко Степан