Чуть меньше года назад, буквально только-только занявшись аццессом, нарисовал программку складского учета и торговли. Понадеявшись на почти фантастическую скорость расчетов с БД у Аццесса, все остатки у меня считаются в он-лайне при формировании какой-нибудь расходной накладной.

Соответственно, по прошествии времени на одном из предприятий накопились сотни тысяч записей прихода и расхода (ах, да, в программе реализован партионный учет, что тоже неслабо влияет на быстродействие), как следствие пересчет остатков занимает уже порядка полутора минут. Это конечно неправильно. Сейчас вот решил (вернее, решил уже давно, сейчас решил начать:), пользуясь багажом полученных здесь и у г-на Гетца новых знаний переписать программу.

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

Зачем нужны остатки. Конечно, для отчетов, где скорость в принципе не важна, плюс для проверки невозможности отпуска товара, которого на складе(ах) нет или недостаточно.
Я обычно для ускорения пересчета остатков пользуюсь одним из следующих методов:

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

2. "Закрыть период". В конце дня/недели/месяца/квартала "закрываю период". Создается запись остатков на конец периода. Все расчеты ведутся от этой записи. Чем больше движение, тем меньше нужен период для быстрых расчетов. Недостатки: редко, и, казалось бы, не совсем "по закону", но бухгалтерии иногда требуется что-нибудь менять задним числом. Естественно, после закрытия периода я запрещаю все изменения.

3. "Инвентаризация". Некий композит из методов 1 и 2. Т.е. закрытием периода является момент инвентаризации. Остатки на начало периода - также запись инвентаризации. Недостатки те же, что в п. 2 + п. 4.

4. Считать остатки "динамически". Т.е. "с начала времен". Очевидные плюсы - можно править приход/расход в любой и за любой момент времени. Минусы - с ростом базы скорость расчета катастрофически падает.
Здесь небольшое лирическое отступление. П. 4. можно реализовывать с вариациями - при вводе расходной накладной мы можем либо сразу расчитать все остатки по всем партиям всех товаров, что тормознет систему при начале заполнения накладной, либо рассчитывать остатки по конкретной партии конкретного товара, что, конечно, хорошо, но надолго ли?

Вот, кажется, и все. Поделитесь, пожалуйста, своим опытом.

Предлагаю поднять тему в понедельник. ибо пора домой.
Да мне, в принципе, не к спеху, но найденный ответ, думаю, мог бы пригодиться всем.

2Nick987 и sasha_1
Это вроде бы правильно. Но.
Предположим такую ситуацию: на складе на 01.01.2001 нет апельсинов. Кто-нибудь берет и задним числом (01.01.2001) ставит расход на n кг этих самых апельсинов. Это нехорошо. Если уж мы разрешаем изменять приход/расход задним числом, то нужно хотя бы контролировать политкорректность этих изменений.

2Nick987
Предыдущая описанная мной ситуация была хотя и возможна, но не слишком часто встречающаяся. Теперь другая, встречающаяся сплошь и рядом. Нужно поправить предыдущий расход (например, случайно указали товар не из той партии). Это не последняя запись - так что считаем остатки с "начала времен". Тоже не есть хорошо. Поначалу я пошел именно таким путем - сделал заплатку на программу, которая так и боролась за высокое быстродействие. Как выяснилось, помогает она примерно в половине случаев. :)

2assa
Очень интересный способ. Не слишком простая реализация, но очень неплохо!
Сейчас припоминаю, что где-то уже видел аналогичное, но, к сожалению, не помню, где :(

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

Вот что я подумал по поводу предложенного тобой метода после 2-х пив:

Cтруктура записи приход/расход:
IdЗаписи/IdНакладной/IdТовара/Цена/Количество/HiddenКолвоПред

Структура записи "остатков на конец периода"
IdТовара/Колво

Что получается:
1. При вводе новой записи товара - HiddenКолвоПред = 0. При изменении записи прихода/расхода HiddenКолвоПред = Количество. Количество = новое значение.
2. При любом вызове пересчета остатков на любую дату пересчитываются все изменения (! - не движение, а только дельты, а их может и не быть) остатков товаров.
Что имеем:
Время расчета остатков будет расти от момента начала периода до его окончания. И, только в случае массовых правок движения товаров задним числом, будет заметное замедление расчета.
Минусы:
Довольно сложные алгоритмы расчетов. И (вроде бы) все.
Но, разве нас не учили, что настоящий пионер/комсомолец/коммунист даже малую нужду должен справлять против ветра? Прорвемся :)

Ошибка, следует читать:

Структура записи "остатков на конец периода"
ДатаНачалаПериода/IdТовара/Колво

2ЛП
Вот он.