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

{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:

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