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

{234,
{"6|","0|","840","USD","0|",0,0,"Доллар США",
{236,
{"6|",20081103,"0|",0,0,0,27.0793},
{"6|",20081104,"0|",0,0,0,27.0793},
{"6|",20081105,"0|",0,0,0,27.0793},
{"6|",20081106,"0|",0,0,0,26.9146},
{"6|",20081107,"0|",0,0,0,26.9114},
{"6|",20081108,"0|",0,0,0,27.0041},
{"6|",20081109,"0|",0,0,0,27.0041},
{"6|",20081110,"0|",0,0,0,27.0041},
{"6|",20081111,"0|",0,0,0,26.9639},
{"6|",20081112,"0|",0,0,0,27.3399},
{"6|",20081113,"0|",0,0,0,27.4704},
{"6|",20081114,"0|",0,0,0,27.6704},
{"6|",20081115,"0|",0,0,0,27.3386},
...
{"6|",20091028,"0|",0,0,0,29.0184},
{"6|",20091029,"0|",0,0,0,29.1749},
{"6|",20091030,"0|",0,0,0,29.3441},
{"6|",20091102,"0|",0,0,0,29.0488},
{"6|",20091103,"0|",0,0,0,29.1944}},
}, 

Естественно, весь код не привожу - он бы просто не влез сюда
Поэтому, вопрос:
Кто и как использует альтернативные системы хранения периодических реквизитах в 1С?
Какие есть мысли по этому поводу?
Отказаться от периодики - не предлагать

Спасибо
А есть еще к-л варианты?
Тоже думал запихать данные в реквизиты регистра и написать класс - но тут есть минус: Надо накладывать доп. индексы и следить за ними в более чем 30 периферийных базах

Z1 писал(а) 03. Ноября 2009 :: 05:53:

Спасибо, хороший вариант
Однако и тут есть свои тонкости -
1. Регламентный пересчет выполняется спец. документом - соответственно, есть возможность отката неправильных результатов перерасчета. В этом варианте такое реализовать достаточно сложно.
2. При создании новых значений мы обязательно должны получить ID справочника. У меня, при разделенных блокировках, при этом блокируется получение новых ID объектов на время транзакции (читай - автообмена) со всеми вытекающими
3. Это скорее голая теория, но число элементов справочника ограничено...

PS Посмотрел сейчас таблицу _1sconst
получается что любое значение хранится в поле
value varchar(256) т.е. ко всему сказанному выше имеем если мы храним цены(числа) то еще и преобразование типов.

И ошибки если мы будем хранить  ID9 скажем ссылку на справочник
а ID переф базы будет 2 символа ( как в соседней ветке 'IV ' ).

slider26 писал(а) 03. Ноября 2009 :: 08:02:

ничего  не понял.
Цитата:

Неявная транзакция ну и что она очень короткая.
Это же не документ с модулем проведения.

Кто Вам сказал что на все таблицы 1с должны быть одинаковые блокировки ? т.е. без  Вашей схемы блокировок вроде и обсуждать нечего.

так у вас проблема с блокировками или с тем что
slider26 писал(а) 03. Ноября 2009 :: 03:44:

может просто историю периодически чистить(или переносить в другую таблицу, если она нужна). Нормальная практика, имхо

alexdd писал(а) 03. Ноября 2009 :: 09:37:

Вместе с документами? Не вариант.

alexdd писал(а) 03. Ноября 2009 :: 09:56:

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

slider26 писал(а) 03. Ноября 2009 :: 10:10:

ну фик знает, если история используется для аналитики, яп ее переносил в другую таблицу, оставляя только необходимую для оперативной работы. А для аналитики вынимать из другой таблицы(или из двух таблиц-архивная+актуальный _1sconst) данные не проблема

Z1 писал(а) 03. Ноября 2009 :: 10:15:

Вариант интересный, спору нет
Думаю, что проблемы с блокировкой все-таки не будет - Внутренний ИД ведь уже есть. Вобщем, надо проверять.
А можно ли реализовать в нем следующую схему (по индексам):
Товар/Тип цен/Дата?

Хочется сравнить все возможные варианты решения и выбрать лучший

slider26 писал(а) 03. Ноября 2009 :: 10:32:

Легко у одного элемента справочника может быть много элементов подчиненных ему.
Также если это нужно то подчиненный справочник может быть многоуровневым.

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