При работе с большими базами данных 1С разработчики часто сталкиваются с проблемой длительной реструктуризации. Добавление нового реквизита или табличной части в крупный справочник может остановить работу компании на несколько часов, а то и суток. В этой статье мы разберем, как можно обойти эту проблему, вынеся хранение табличной части в отдельный регистр сведений, и какие архитектурные подходы для этого существуют.
Проанализируем ситуацию: у нас есть очень большой справочник, и для некоторых его элементов необходимо хранить списки дополнительных значений. Структура этих списков может меняться в будущем, что потребует новых реструктуризаций. Наша задача — найти гибкое решение, которое минимизирует простои системы.
Основная причина, по которой разработчики ищут альтернативы, — это процесс реструктуризации таблиц в SQL. Когда вы добавляете новый реквизит или табличную часть в объект конфигурации 1С, платформа выполняет команду ALTER TABLE на уровне СУБД. На базах данных размером в сотни гигабайт или терабайты этот процесс может быть очень долгим.
Хотя в платформе 1С появился механизм отложенной реструктуризации (так называемая V2), он не всегда является панацеей. На очень больших базах данных даже этот механизм может выполняться часами, создавая значительную нагрузку на сервер. Если вы заранее знаете, что структура данных будет меняться, а новые данные нужны лишь для небольшой части элементов, имеет смысл рассмотреть хранение этих данных в отдельном регистре сведений.
Это самый очевидный и простой для понимания подход. Каждая строка вашей табличной части будет соответствовать одной записи в регистре сведений. Структура регистра в этом случае будет выглядеть так:
Объект — ссылка на ваш справочник (например, СправочникСсылка.Номенклатура). Это измерение будет связывать записи регистра с конкретным элементом.НомерСтроки — тип Число. Необходимо для сохранения порядка строк, как в обычной табличной части.РеквизитТЧ1 — соответствует первой колонке табличной части.РеквизитТЧ2 — соответствует второй колонке.Преимущества:
Недостатки:
ХранилищеЗначенийЭтот подход кардинально отличается от предыдущего. Мы не будем хранить каждую строку отдельно, а упакуем всю табличную часть в один объект и поместим его в единственный ресурс регистра.
Структура регистра будет предельно простой:
Объект — ссылка на ваш справочник.ДанныеТаблицы — тип ХранилищеЗначений.Логика работы следующая: при записи данных вы программно формируете ТаблицуЗначений, заполняете ее, а затем помещаете в ресурс регистра.
// Пример записи данных
НоваяЗапись = РегистрыСведений.МоиДанныеТЧ.СоздатьМенеджерЗаписи();
НоваяЗапись.Объект = СсылкаНаЭлементСправочника;
// Создаем и заполняем таблицу значений
ТаблицаДляХранения = Новый ТаблицаЗначений;
ТаблицаДляХранения.Колонки.Добавить("Колонка1", Новый ОписаниеТипов("Строка"));
ТаблицаДляХранения.Колонки.Добавить("Колонка2", Новый ОписаниеТипов("Число"));
НоваяСтрока = ТаблицаДляХранения.Добавить();
НоваяСтрока.Колонка1 = "Значение 1";
НоваяСтрока.Колонка2 = 123;
// Помещаем таблицу в хранилище
НоваяЗапись.ДанныеТаблицы = Новый ХранилищеЗначений(ТаблицаДляХранения);
НоваяЗапись.Записать();
// Пример чтения данных
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| МоиДанныеТЧ.ДанныеТаблицы
|ИЗ
| РегистрСведений.МоиДанныеТЧ КАК МоиДанныеТЧ
|ГДЕ
| МоиДанныеТЧ.Объект = &Объект";
Запрос.УстановитьПараметр("Объект", СсылкаНаЭлементСправочника);
Результат = Запрос.Выполнить().Выбрать();
Если Результат.Следующий() Тогда
// Извлекаем данные из хранилища
ИзвлеченныеДанные = Результат.ДанныеТаблицы.Получить();
Если ТипЗнч(ИзвлеченныеДанные) = Тип("ТаблицаЗначений") Тогда
// работаем с таблицей
КонецЕсли;
КонецЕсли;
Преимущества:
ТаблицеЗначений без каких-либо изменений в конфигурации. Реструктуризация не потребуется никогда.Недостатки:
Этот подход является золотой серединой между гибкостью и возможностью выполнять запросы. Он похож на механизм дополнительных реквизитов, встроенный в платформу. Идея в том, чтобы хранить имя "колонки" не в структуре конфигурации, а как данные в отдельном измерении.
Такая структура регистра — наиболее гибкое и мощное решение для нашей задачи:
Объект — ссылка на ваш справочник.НомерСтроки — тип Число. Для группировки реквизитов одной строки.Реквизит — ссылка на ПланВидовХарактеристик или просто тип Строка, где будет храниться имя "колонки" (например, "Цена", "Количество", "Поставщик").Значение — тип Характеристика.<ИмяПВХ> или составной тип данных, если вы не используете ПВХ. В этом ресурсе будет храниться само значение.Как это работает: одна строка вашей виртуальной табличной части будет храниться в регистре как несколько записей. Например, строка `{Артикул: "Т001", Цена: 1500}` для объекта "Товар А" и `НомерСтроки = 1` будет представлена двумя записями в регистре:
Преимущества:
Реквизит. Никаких изменений в конфигураторе не требуется.Реквизит = "Цена" и Значение > 1000.ПланВидовХарактеристик и РегистрСведений.Недостатки:
Выбор способа хранения данных зависит от конкретной задачи. Давайте подведем итог:
ХранилищеЗначений.Плана видов характеристик.Для изначально поставленной задачи — хранение списка доп. значений неопределенной величины со структурой, которая будет меняться в будущем, — третий способ (EAV) является наиболее подходящим и профессиональным решением. Он позволяет избежать реструктуризации и при этом сохраняет возможность анализа хранимых данных средствами языка запросов.