Системное хранилище настроек 1С

Question

Всем доброго дня. 

Нужен совет достаточно продвинутых прогеров. Недавно столкнулся с одной обработкой (внешней обработкой) написанной для ЕРП/УТ/КА (версия релиза не важна).

В общем, в программном коде этой обработки вводятся такие понятия, как виртуальные объекты.
[1C-CODE]// *** Префиксы в именах процедур и функций.                          
//
//	  * ВО... - виртуальные объекты (виртуальные справочники и документы). Виртуальные объекты - это имитация существования в конфигурации
//				справочников и документов, на самом деле отсутствующих в конфигурации. 
//				Примеры виртуальных объектов:
//				- Справочники: "_РезультатыПосещений", "_ШаблоныАнкет";                                  
//				- Документы: "_Мерчендайзинг", "_Посещение".
//	  * ВДок...	- виртуальные документы (см. описание "ВО...")
//	  * ВСпр... - виртуальные справочники (см. описание "ВО...")
[/1C-CODE]

Обработка работает так: есть форма списка документов, а есть форма непосредственно самого документа (Правильнее будет сказать - обычная форма внешней обработки). Объект формы (в обоих случаях) - это естественно (ВнешняяОбработка.ИмяОбработки.). В этом плане никаких непонятностей нету. Когда надо сохранить документ (например, командой "Провести и закрыть" на форме внешней обработки) система сохраняет объект формы в хранилище системных настроек (дополнительно перетаскивает туда ГУИД формы для уникальности записи) вот таким незатейливым кодом:
[1C-CODE]// Сохранение виртуального объекта в хранилище значений (и самого объекта и обновление таблицы виртуальных объектов данного вида). 
// Параметры: 
// 	 СтррВО - Структура - системные свойства виртуального объекта (результат вызова функции ВОСвойстваОбъекта()).
// 	 GUID 	- УникальныйИдентификатор - идентификатор объекта.
// 	 СтррОбъект - Структура - сохраняемый виртуальный объект.
//
Процедура ВОЭлементСохранить(СтррВО, GUID, СтррОбъект) Экспорт

	// Этап 1. Сохранение самого элемента в хранилище.	
	СохранитьОбъектВХранилище(СтррВО.Префикс, GUID, СтррОбъект);
	
	// Этап 2. Обновление в хранилище ТЗ списка элементов
	ТЗн = ВОТЗЗагрузить(СтррВО, Истина);
	
	СтрокаТ = ТЗн.Найти(GUID, "ID");
	Если СтрокаТ = Неопределено Тогда
		СтрокаТ = ТЗн.Добавить();
		СтрокаТ.ID = GUID;
	КонецЕсли;
	
	ЗаполнитьЗначенияСвойств(СтрокаТ, СтррОбъект);
	
	ВОТЗСохранить(СтррВО, ТЗн);

КонецПроцедуры

// Процедура сохраняет заполненную структуру объекта в хранилище.
// Параметры:
//   Префикс - Строка - префикс, используемый в качестве имени значения из хранилища.
//   UUID - УникальныйИдентификатор - идентификатор объекта.
//   СтррОбъект - Структура - сохраняемый объект в виде структуры.   	
Процедура СохранитьОбъектВХранилище(Префикс, UUID, СтррОбъект) Экспорт

	СохранитьЗначениеНастройки(Префикс + Строка(UUID), СтррОбъект);

КонецПроцедуры

// Сохраняет значение настройки в ХранилищеСистемныхНастроек.
// Параметры:
//   ИмяНастройки - Строка - название настройки.
//   Значение - Произвольный - значение настройки.
Процедура СохранитьЗначениеНастройки(ИмяНастройки, Значение) Экспорт

	ХранилищеСистемныхНастроек.Сохранить(КлючНастроекОбмена(), ИмяНастройки, Значение, , ПользовательНастроек());
		
КонецПроцедуры


[/1C-CODE]

Я просто впервые вижу такой способ использования хранилища системных настроек. Т.е. фактически, для хранения новых документов используются не новые объекты конфигурации (как обычно это делается), - а непосредственно хранилище системных настроек.

Собственно говоря, вопрос: Насколько это целесообразно, вообще, с учетом того, что самих документов у организации может быть сотни тысяч (за пару лет работы), а может быть и больше. У меня есть задача, сделать регламент, который будет генерировать некоторые виды документов автоматом, по определенному алгоритму. И я как то "застеснялся" такой регламент делать, из за особенностей этой обработки. В общем нужен совет "бывалых")) 

Я склоняюсь все таки к тому, что бы создать отдельный объект конфигурации (отдельный документ в конфигурации) и с ним уже работать. Но придется изменить алгоритм самой обработки для этого., что бы она работала уже не с хранилищем настроек, а непосредственно с самим новым документом.

Accepted Answer

1. Хранилище системных настроек - это таблица [dbo].[_SystemSettings].
То, что вы туда пихаете лежит в поле [_SettingsData] типа Image - т.е. это BLOB со всеми вытекающими затратами на хранение, извлечение и конвертацию в нужный тип 1С.

2. Надеюсь, объяснять, что вы теряете, используя вместо документов, какие-то структуры, хранимые в двоичных данных не надо.

3. У внешней обработки не так много вариантов сохранять свои данные, но один из самых неоптимальных - ваш вариант. Хотя бы потому, что вы пихаете множество данных в таблицу, где еще много всякого хранят всякие разные.

4. С вероятностью 99,9% - такое вот использование  для множества документов - это плохая архитектура.
А при наличии расширений вообще надо хорошо подумать зачем такое вообще могло понадобиться.

Есть экзотические варианты, например, в области "защиты" данных хитромудрым разработчиком от вас. Своеобразный архив перед удалением и т.п. В эти дебри лезть желания нет.
Но и тут одно из наихудших решений - приведенное вами.

В общем, добрый совет - поймите задачу и сами разработайте архитектуру с авторами этой обработки лучше не советоваться.