Где хранятся свойства номенклатуры 1С: структура и таблицы

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

В зависимости от режима совместимости и типа платформы, данные могут храниться как в классических таблицах, так и в виртуальных таблицах с приставкой _R или _T. Ключевым моментом является различие между предопределенными полями, которые известны системе заранее, и динамическими реквизитами, добавляемыми пользователем в процессе эксплуатации. Именно последние часто становятся причиной путаницы при попытке написать прямой SQL-запрос к базе данных Microsoft SQL Server или PostgreSQL.

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

Основная таблица справочника Номенклатура

Центральным элементом хранения информации о товаре является основная таблица справочника. В базе данных она обычно имеет имя _Reference123, где цифры — это уникальный идентификатор метаданных, присвоенный конфигурации. Именно здесь располагаются все предопределенные реквизиты, такие как Наименование, Код, Артикул и Родитель. Доступ к этим данным через объект метаданных всегда осуществляется быстро, так как они лежат «на поверхности».

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

⚠️ Внимание: Никогда не полагайтесь на жестко заданные номера таблиц (например, _Reference123) в своих скриптах. При обновлении конфигурации или пересоздании базы идентификаторы могут измениться, что приведет к неработоспособности ваших внешних интеграций. Используйте системные представления или запрашивайте имена таблиц через метаданные.

Важно отметить, что таблица содержит также служебные поля, такие как _Marked (пометка удаления) и _IsFolder (признак группы). Эти флаги имеют критическое значение при формировании выборок, так как игнорирование пометки удаления может привести к попаданию в отчеты уже удаленных, но не проведенных окончательно позиций. Программист должен всегда учитывать эти битовые маски при написании сырых SQL-запросов.

Механизм хранения дополнительных реквизитов

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

Чаще всего встречается вариант, когда все дополнительные реквизиты сводятся в единую таблицу значений или хранятся в виде строк с разделителями в старых версиях. Однако наиболее распространенный и правильный подход в актуальных релизах — это использование таблицы _AddInfo или аналогичной структуры, связанной с основным справочником по ссылке _RefID. В этой таблице каждая строка соответствует одному значению конкретного свойства для конкретного элемента номенклатуры.

• 📦 Таблица дополнительных сведений хранит пары «Идентификатор свойства — Значение».
• 🔗 Связь с основным элементом осуществляется через уникальный GUID номенклатуры.
• 📝 Тип данных в ячейках часто универсальный (строка или число), что требует приведения типов при выборке.

Такой подход обеспечивает гибкость: вы можете добавить хоть сто новых полей, не перестраивая основную таблицу справочника и не создавая сотни новых колонок в SQL Server. Это существенно экономит место в журнале транзакций и ускоряет операцию изменения структуры метаданных. Однако, с точки зрения производительности сложных выборок с фильтрацией по этим полям, такой механизм может быть менее эффективным, чем прямые колонки.

Особенности хранения характеристик номенклатуры

Характеристики номенклатуры — это отдельный сущностный слой, который часто путают с обычными реквизитами. Характеристика в 1С представляет собой полноценный справочник, подчиненный справочнику Номенклатура. Это означает, что физически данные о характеристиках хранятся в отдельной таблице, связанной с основным товаром.

Каждая характеристика имеет свой уникальный идентификатор и набор свойств, которые могут отличаться от свойств родительского товара. Например, у товара «Футболка» свойством является цвет, а у характеристики «Футболка, Красная, XL» свойствами могут быть конкретный оттенок и размер. В базе данных это реализуется через таблицу _Reference[ID_Характеристик], где есть поле ссылки на основную номенклатуру.

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

⚠️ Внимание: Убедитесь, что в вашей конфигурации включена функциональная опция «Использование характеристик». Если она отключена, соответствующие таблицы могут отсутствовать или не использоваться, даже если метаданные формально присутствуют в конфигураторе.

Для оптимизации запросов к характеристикам рекомендуется использовать индексированные поля ссылки. Поскольку связь «один ко многим» (один товар — много характеристик) является стандартной, СУБД обычно хорошо справляется с такими соединениями, но при объемах данных в миллионы записей может потребоваться дополнительный анализ планов выполнения запросов.

Таблицы серий и упаковок

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

Упаковки представляют собой еще один уровень детализации. Информация о том, в какой таре хранится товар (коробка, паллета, штуки), часто содержится в регистрах накопления или отдельных справочниках видов упаковок. При формировании отчетов по остаткам необходимо учитывать коэффициент пересчета, который хранится в соответствующих таблицах настроек.

Объект данных	Тип хранения	Основная таблица (пример)	Ключевое поле связи
Номенклатура	Справочник	_Reference123	_RefID
Характеристики	Справочник (подчиненный)	_Reference456	_Fld1234RRef (Ссылка на товар)
Серии	Регистр сведений	_AccRg567	_Fld789RRef (Ссылка на товар)
Доп. реквизиты	Таблица доп. сведений	_AddInfo890	_RefID (Ссылка на объект)

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

Влияние версий платформы на структуру БД

Архитектура хранения данных в 1С претерпевала изменения на протяжении многих лет. В версии 7.7 все данные хранились в табличном виде, максимально приближенном к реляционной модели, где каждый реквизит был отдельной колонкой. С приходом платформы 8.0 и последующих версий 8.1, 8.2, 8.3 введена сильная абстракция, позволяющая менять структуру метаданных без пересоздания таблиц.

В современных конфигурациях на платформе 8.3.10 и выше активно используется механизм виртуальных таблицей. Это означает, что то, что вы видите в консоли управления базами данных, может не совпадать с тем, что видит запрос 1С. Система динамически формирует представления (Views) для упрощения доступа к данным, скрывая сложность физических соединений.

Что такое таблица _Mode80?

Это служебная таблица, которая появлялась в переходных версиях платформы для эмуляции поведения старых объектов. В современных базах она обычно не используется для хранения пользовательских данных, но может встречаться в старых архивах.

Разработчикам, пишущим внешние обработки или интеграционные модули, следует ориентироваться на актуальную документацию по версии платформы, установленной на сервере. Поведение оптимизатора запросов и способ хранения больших текстовых полей (хранятся ли они в основной строке или выносятся в LOB-объекты) может существенно влиять на скорость работы.

Практические примеры SQL-запросов

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

SELECT
T._Description AS Name,
A._Value AS AdditionalProperty
FROM
_Reference123 T
LEFT JOIN
_AddInfo890 A ON T._RefID = A._RefID
WHERE
T._Marked = 0x00
AND A._PropertyID = 0x1234567890ABCDEF

В этом запросе мы используем LEFT JOIN, чтобы не потерять товары, у которых данное свойство не заполнено. Фильтр _Marked = 0x00 гарантирует, что мы не получим удаленные элементы. Обратите внимание, что идентификатор свойства (_PropertyID) нужно знать заранее, его можно получить из таблицы описания дополнительных реквизитов.

• 🚀 Используйте EXISTS вместо JOIN, если вам нужна только проверка наличия свойства.
• 🔍 Всегда проверяйте тип данных в поле значения, чтобы избежать ошибок преобразования.
• ⚙️ Для больших выборок создавайте временные таблицы с индексами.

Если вы работаете с характеристиками, запрос усложнится добавлением еще одного соединения. В высоконагруженных системах (HighLoad) такие запросы лучше кэшировать или выносить в отдельные регистры сведений, обновляемые по расписанию.

⚠️ Внимание: Прямые SQL-запросы обходят механизм блокировок 1С. Если в момент выполнения вашего запроса пользователь будет проводить документ, изменяющий этот товар, вы можете получить несогласованные данные (грязное чтение). Используйте уровень изоляции транзакций с осторожностью.

Оптимизация и лучшие практики

Работа с таблицами номенклатуры требует соблюдения определенных правил для поддержания высокой производительности системы. Главная рекомендация — минимизировать использование прямых обращений к таблицам дополнительных реквизитов в циклах. Лучше загрузить необходимые данные одним большим запросом в память и обрабатывать их средствами языка 1С.

Регулярный анализ индексов в СУБД помогает выявить «узкие места». Часто оказывается, что по полям, используемым для фильтрации в отчетах (например, «Вид номенклатуры» или «Бренд»), отсутствуют индексы, что приводит к полному сканированию таблицы (Table Scan). Добавление индекса на уровне базы данных должно согласовываться с разработчиком конфигурации.

Также стоит обратить внимание на механизм обновления статистики в СУБД. Если статистика устарела, оптимизатор может выбрать неверный план выполнения, например, пойти по вложенным циклам вместо hash join, что замедлит работу в разы. Автоматическое обновление статистики должно быть включено на сервере баз данных.

Можно ли добавлять поля прямо в таблицу SQL?

Технически это возможно, но категорически не рекомендуется. При обновлении конфигурации 1С может пересоздать таблицу, и ваши изменения будут потеряны. Кроме того, это нарушает целостность метаданных, и платформа может некорректно работать с таким объектом. Используйте механизм дополнительных реквизитов внутри конфигуратора 1С.

Где хранится история изменений свойств?

Сама платформа 1С не хранит историю изменения значений реквизитов справочника по умолчанию. Для этого необходимо регистрировать изменения в специальных регистрах сведений с помощью механизмов подписки на события или записывать историю вручную в документы «Изменение свойств».

Как найти ID таблицы номенклатуры?

Имя физической таблицы зависит от идентификатора метаданных. Чтобы узнать его, откройте конфигуратор, найдите справочник Номенклатура, посмотрите его свойства (вкладка «Основное») — там будет указан ID. Либо выполните запрос к системной таблице метаданных в самой базе SQL.

Влияет ли количество доп. реквизитов на скорость?

Да, влияет. Большое количество дополнительных реквизитов увеличивает размер таблицы расширений и усложняет запросы, требующие соединения с ней. Если реквизитов очень много и они активно используются для отборов, рассмотрите возможность вынесения их в отдельные справочники или регистры.