есть такой вот запрос:

ВЫБРАТЬ
    Список.Код КАК номер,
    Список.ФлагРемонт как ремонт,
    Список.КонтрагентАналитика как аналитика,
    Список.ТипПользования как пользование,
    МАКСИМУМ(Дислокация.ДатаПолучения) КАК макс_дата
ПОМЕСТИТЬ Дислокация_архив
ИЗ
    Справочник.ДислокацияВагоныСписок КАК Список
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ДислокацияВагоныАрхив КАК Дислокация
        ПО Список.Код = Дислокация.Номер

СГРУППИРОВАТЬ ПО
    Список.Код,Список.ФлагРемонт,Список.КонтрагентАналитика,Список.ТипПользования
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    Дислокация2.Номер,
    Дислокация2.Тип,
    Дислокация2.Статус,
    Дислокация2.СтанцияНазначения,
    Дислокация2.Оператор,
    Дислокация2.Расстояние как Раст,
    Дислокация_архив.ремонт,
    Дислокация_архив.Аналитика,
    Дислокация_архив.пользование как Польз
ИЗ
    Справочник.ДислокацияВагоныАрхив КАК Дислокация2
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ Дислокация_архив КАК Дислокация_архив
        ПО Дислокация2.Номер = Дислокация_архив.номер
            И Дислокация2.ДатаПолучения = Дислокация_архив.макс_дата


есть два справочника:
ДислокацияВагоныСписок (в нем номера жд вагонов)
ДислокацияВагоныАрхив (история движений вагонов)
1 часть запроса выбирает  для каждого вагона макс дату - дату последних зарегенных сведений
2 часть - делает отбор из архива по максимальной дате (последние сведения) для каждого вагона.

база файловая, список вагонов 100 шт, архив движений - записей 150 тыс.
после добавления новых данных по движениям  - запускаю запрос, выполняется минуту где-то,
делаю запрос на выполнение раз 5-6 и  потом через некоторое время - мгновенно выполняется, на сервере я один, память и проц не перегружены.

это какие-то особенности 1с. почему так происходит?

кэширование

(1) +1

зачем каждый раз считать одно и то же? вот и система кэширует запросы и их результаты и если источник не менялся, то и результат не меняется

ДислокацияВагоныАрхив (история движений вагонов)
Номер (номер вагона, число) соединение по нему в запросе
ДатаПолучения (дата) соединение по нему в запросе
Статус (текст)
эти три поля индексируемые, остальные нет (не стоит галка "индексировать")

т.е. если кэш очищу у пользователя - будет опять медленно?
сча попробую проверить

c:\Documents and Settings\ХХХ\Local Settings\Application Data\
c:\Documents and Settings\ХХХ\Application Data\

удалил все внутри по 1с

запрос все мгновенно выполняется

А как вы планировали кэш в оперативной памяти почистить? То что вы удалили - это всего лишь временные файлы 1С.

Какой ВУЗ заканчивали?

перегрузил серв - опять долго значит кэширование.

(8) ВУЗ к IT не имел отношения, 1с-ю для себя, свою работу пытаюсь автоматизировать аля хочу "одну кнопку" :)

Ясно :)

первый раз идет выполнение сек 30, потом мгновенно. ну и фиг с ним.

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

а так сама логика запроса верна?
а то мож не так что у меня там сделано?
база файловая, список вагонов 100 шт, архив движений - записей 150 тыс.
вроде не большой обьем данных чтоб тормозило так

(0) Реализуете периодические регистры сведений на справочниках? Да еще и связываете их не по уникальным ключам? Круто.

А теперь представьте как это всё будет работать, когда объем данных по дислокации накопиться на несколько миллионов записей. А произойдет это очень быстро даже если у вас парк небольшой.

>> сама логика запроса верна?
Запрос недоделанный.
Но проблема не в логике запроса, а в структуре и логике исходных данных.

>> если что заведу отдельный справочник

таки да - актуальная (текущая, оперативная) дислокация должна, скорее всего, храниться отдельно от исторических данных. Но использовать для этого справочник... А чё не документы или бизнес-процессы? Вагон едет - бизнес-процесс адназначна....

в данном случае движения - это история движения в пути

т.е. например есть у меня документ, отправка вагона "Москва-Питер" - это именно документ

а вот как он ехал в пути от Москвы до Питера - это аля справочная инфа и храниться она в "справочнике" архиве дислокации

итого есть отдельно список вагонов за которыми слежу, и инфа - история его движений архив.

из архива я могу узнать на опр. время получения данных о нахождении где вагон был.

т.е. грубо номер вагона, дата получения справки, место нахождение.

как по канонам разработки правильно организовать хранение истории движений, чтоб запросы не тормозили:
список вагонов - узнать последнюю дислокацию по ним всем.

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

(15) Вот и я говорю - дебильная логика.

>> это аля справочная инфа.

Это а-ля инфа о состоянии объекта (вагона), развернутая во времени (изменяющаяся во времени).
И то, что вам нужны отчеты типа (0), доказывает мои слова.
То есть речь идёт о типичном регистре сведений.
Однако вы его упорно пихаете в справочник и удивляетесь почему у вас всё медленно работает.
Удивляйтесь дальше.

(18) ну я же тока учусь :) спасибо за помощь!
упорно пихаю по незнанию и отсутствия опыта.

т.е. мой запрос только уже к регистру через "срезпоследних" - не будет уже тормозить?

эти итоги по последней инфо уже в структуре данных регистра будут храниться и агрегироваться платформой и поэтом к ним быстрый доступ будет без вычислений?

т.е. типа моего доп справочника с последними акт. данными

(14) тоже к жд перевозкам имеете отношение?

(20) Да, он не будет тормозить.
Логика твоя чем-то похожа на механизм ОС типовых. Посмотри, как там реализовано.

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

http://catalog.mista.ru/public/527518/
курю

(0) файловая - песочница
будь мужиком, блеать - переходи на скуль
историю лучше в РС

Хорошая попытка, РЖД

(26) ?