У нас в компании пользуются 1с7 + самописная конфигурация с 2006 года.
Сейчас стал вопрос о "архивации" старых документов, дабы убыстрить работу программы, идею по архивации предложил программист который это конфигурацию изначально написал.
Суть ее в следующем (вкратце, основные моменты):
создается новый документ, в нем должна хранитьcя информация по сальдо например с 2006 по 2008 гг. Что значит по сальдо, например есть регистр "склад" есть документы которые двигают его в + и есть которые двигают в -
и есть отчет в котором можно посмотреть конечное сальдо или сформировать отчет по документам (каким документом был приход а каким расход). Ну так вот в этом документе должны находиться такиеже позиции как и в отчете на определенную дату к примеру на конец 2008 года.
и вроде как по его словам это убыстрит работу системы т.к. будет проводиться один документ на не все скопом (кстати у нас каждый вечер все документы перепроводятся в системе)
Сделал я такой док, сформировал отчет, засек время на обработку запроса ~45 c. (это по сальдо), провел созданный мною документ, проводок в регистре стало в 2 раза больше и сальдо увеличилось в 2-е,
сформировал заново отчет время на обработку запроса такое же. Вопрос, так в чем эта затея может убыстрить систему? Да время на перепроведение ночью будет затрачено меньше, но только ради этого думаю не стоит заморачиваться,
к тому же там столько подводных камней, что боюсь потом не разгребусь.

(0) а старые документы сделали не проведенными?

(1) да

формат базы какой?

(3) sql (я думаю вы это имели ввиду)

(4) тогда это особого смысла не имеет. Достаточно регулярно переиндексироватся и обновлять статистику

(5) вот и я так думаю. Код переиндексации таблицы sql у меня есть, а что значит обновлять статистику?

(6) dbcc updatestatistics
Почитай в литературе по sql про то, как строятся планы запросов по полям, по которым нет индекса

(7) продай ему BOL :-)))

(8) БОЛ не могу пока, с билли не договориться никак...

(7) что-т не найду, поделиться литературой если есть

(10) Скуль-сервер стоит? документацию к нему установил? Там всё есть.

(9) можно подумать, насчет СП ты с Борей договорился... :-D

(12) подумать можно :-)

(13)
Штирлиц подумал...
ему понравилось...
"А не подумать ли еще", подумал Штирлиц...
©

Ничего не понял из (0)

(15) не страшно

Как может быть сальдо С .. ПО .. ???

Или все движения из разных документов перенсети в 1???

(17) а я так написал )) знач ошибся, не с  по а на дату

У тебя каждое предложение - взаимоисключающие параграфы

Кстати а если вместо sql 2000 (его счас юзаем) заюзать 2005 это будет производительней? или разницы особой не будет?

(20) ну я не на форуме русского языка, я даже не знаю что такое "взаимоисключающие параграфы" :D

(21)Перейти то можешь, но лучше все таки на 2000 - 1с штатно не держит 2005 и 2008 SQL

(23) понял

+(23)я про 1с77 говорю

(17) динамическое :-D

очень насторожила фраза
(кстати у нас каждый вечер все документы перепроводятся в системе)

что-то в консерватории не так

(27) Восстановление последовательности ?

(28) наверное...
с 2006 года...
каждый день...

ЗЫ если это так - то это очень быстрая база

(27) ну так ее изначально написали.
Например что-то подправили в старом документе (такое у нас считается нормальным явлением) и что бы это отразилось в регистре, и что бы другие связаные документы были актуальные нужно перепроводить.
(29) да уж... с 10 вечера до 5 утра )))

а какие еще есть варианты, тут ничего не поделаешь

(5) так  чо свертка для SQL ной базы не имеет смысла?

(32) да.

(27)(30) к сожалению, у нас так же - приходится ежевечерне подтягивать последовательность, ибо pit так и не поделился секретным знанием...
правда, у нас это делается в разделенном режиме (ибо 24*7) и т.п. Но процедура пересчета своя...

(30) установи дату запрета редактирования документов.

(35) Если б это решало проблему....

(33)(36) так все таки раскройте тему ширее как данные в прошлых периодах влияют на работу регистра в текущем периоде (к примеру при проведении документа на ТА). ТС-у наверное тоже это интересно.

(37) Да никак. Точнее, влияют - но как и положено по математическим правилам...
А что касается их наличия, то никак не влияет, особенно если работа в основном ведется в одном периоде - ибо сиквелд достаточно хорошо кэширует данные...

(30) если проблема "медленной работы" только в перепроводке документов, то для начала попробуй ReconectNative() из 1cpp, а еще лучше перепиши основные модули проведения (в частности расчет остатков) на прямые запросы.
После этих манипуляций скорость перепроводки сильно возрастет.

(39)+ кстати, если перейти на 2005 скуль - то перепроводка документов будет идти шустрее (погугли про проблему замедления на 2000 скуле, ReconectNative() как раз костыль для этого).
Но лично я сомневаюсь, что 77+2005=стабильная связка

(40) если (0) перейдет на скуль 2005, то на базе семерочной все равно придеться ставить галку совместимости со скулем 2000, врядли сильно ускорит, то что скуль 2005 будет пытаться работать, как скуль 2000
(0) советую просто сделать свертку базы, информация по сверке и как ее делать и обработки должны быть на ИТСе

(41) никто не говорит об ускорении базы на 2005 скуле. Разговор про глюк 2000 скуля, который МС так и не исправила. в 2005 этого глюка нет, даже в режиме совместимости.

(42) не буду спорить, не моя база, не мне перепроводить все документы с 2006 года каждый рабочий день :)
Но если сделать свертку, то база должна стать существенней легче, учитывая, что она аж с 2006, не свернутую(старую) хранить только для просмотра старых документов,а в новой(свернутой) спокойно пару лет еще работать, тогда не будет необходимости замены скуля на более новый, переписывать часть модулей на прямые запросы...А можно и все вместе варианты(свертка,скуль2005,прямые запросы,сервер проапгредить) сделать хД

(41) а где кроме итс можно почитать про свертку?
(39) что такое прямые запросы?

похвастаюсь...

у меня комплексная база нерезанная с 2002, в день 300-400 расходных документов (среднее кол-во позиций 48).
Перепроводка в разделенном режиме (перепроводка задним числом) 200-300 мс на один документ.

Параметры сервера на уровне добротной домашней машины

(44) смотри форум на 1cpp.ru - там есть "методичка" для начинающих

(45)+ http://www.1cpp.ru/forum/YaBB.pl?num=1148874473

(45) 7.7 ? А весит база уже сколько ?

(47) 23гб

(44) Книга знаний: Обрезание (сверка) базы и
v7: Свертка самописной базы почитай

(48) и ни слова про платформу ;)

(50) ну так ветка же про 7.7
У меня в частности 7.7 (27) + скуль 2000сп4

неее обрезать нельзя, как я понял из (49) это подбить остатки и удалить доки со всеми связями. Что-т я слабо представляю как же это убрать основание (старые доки) что бы все еще коректно после этого работало

(52) то что ты описывал в (0) - это та же свертка, только чуть-чуть не доконца выполненная

(53) да помне то что я описал в (0) это гемор на мою опу )))
(46) скачал, бегло пробежался (завтра почитаю внимательнее) но там речь идет о выборке о обработке запросов, это убыстрит формирование отчетов, а проведение? в смысле движение регистров (приходвыполнить расход...) там не увидел такого

(45)
хе-хе
В разделенном режиме (правда по ночам) 120-140мс - обычное дело. Иногда бывает и 70-100, но редко.

(54) обычно в модулях проведения тормозит расчет остатков  задним числом. Время на расчет может достигать 99% от всего времени проведения документа.
Вот эту часть и нужно ускорять.

Сделай простой тест:
Запусти Отладчик, поставь замер производительности. Дальше нажми F11 - откроется предприятие, запусти перепроводку документов за неделю.
После того как закончится перепроведение возвращайся в Отладчик, останавливай замер и смотри на что тратится основное время.

Можешь сюда запостить первые 10 строк замера

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