TORTКрутая у вас таблица получится.... Кол-во номенклатур * Кол-во дат.... = ? Со временем таблица еще больше получится....Ну если по большей части номенклатур остатки меняются относительно редко, то и не надо по ним остатки на каждую дату хранить. Добавлять записи, только при изменении остатка. Табличка будет не больше, чем таблица движений, а остатки безо всякого суммирования будут получаться.

TORTЕсли остатки меняются редко, то и записей о движении будет немного, а следовательно и
select sum(...) будет работать недолго....ИМХО... Зачем огород городить?
Типичная структура движений такова: из 10-20 тысноменклатурных единиц по 95 процентам движения происходят пару раз в месяц. Процентам по 4 - раз в два-три дня, а по оставшимся - несколько раз в день. Соответственно для 95 процентов вполне можно и суммировать (за год накопится 20-30 записей), но вот по этому проценту (а именно по нему остатки нужны наиболее часто) суммировть потребуется уже довольно много. Соответственно имея записи об остатках на моменты движений мы не раздуваем существенно таблицу остатков, но зато время получения остатка не зависит от активности номенклатуры.

TORTПоправьте меня, если я заблуждаюсь...Поправляю.

Имеем таблицу
При совершении движения в этой таблице у текущей записи по номенклатуре выставляется "Конец" и добавляется новая. Если в один день происходит несколько двжиений, то мы просто модифицируем запись текущую запись.
Таким образом число записей не превышает количества движений, а остаток на любой день достается запросом без суммирования:
Наличие индексов делает запрос быстрым. Особые эстеты могут его оптимизировать.
Я не говорю, что это единственное верное решение, но в некоторых случаях оно работает очень хорошо.

TORTЯ не совсем понимаю зачем Начало и Конец... Поясните, если не трудно...Для того чтобы не делать sum и не хранить остатки за все даты.

TORTЯ не совсем понимаю зачем Начало и Конец... Поясните, если не трудно...Да, я понял - вы хотите сказать, что можно обойтись только Началом. Можно, но в этом случае запрос для получения значения будет более сложным - без подзапроса не обойтись.

TORTСпасибо за подробное пояснение... Но все-таки хотелось бы уточнить... Таким образом Вы предлагаете хранить интервалы, на которых остатки были неизменными? Я правильно понял? Да, правильно.

TORTВы тестировали данный подход? Если не серкНе только тестировал, но и промышленно эксплуатировал. :)

TORTЕсли не секрет на каой СУБД? Какой интервал движения? И какое кол-во номенклатур?О СУБД вы могли из моего профиля догадаться - Oracle. Но думаю, что такой подход мог бы на любой СУБД использоваться.
Количественные характеристики: из реально работающих есть примеры в которых более 100 тысяч учетных единиц и сотни тысяч движений в день. Но это мало о чем говорит, так как надо учитывать используемую технику и то, что реальные системы не только движения учитывают. Голый тестовый пример для сравнения этой модели с другими я не собирал.

TORTВопрос с реализацией? Как формируется такая таблица? Триггеры, специальная ХП, клиентское приложение?Триггеры или ХП - это не очень интересный вопрос. У нас было несколько реализаций. Стандартно была процедура, добавляющая движения, она же и остатком занималась. Но в триггере это выглядело бы точно так же.
Гораздо более интересный вопрос с обеспечением сериализации - если несколько сеансов одновременно делают движения по одной и той же учетной единице. В общем-то обычная блокировка здесь помогает, но был у нас один исключительный случай, когда учетных единиц было мало (порядка сотни), а конкурирующих транзакций - много (до полусотни процессов и десятки тысяч операций в час у каждого). Тут задержки на блокировках становятся посущественней. Для этого случая был другой вариант, когда заполнением этой таблицы занимался отдельный фоновый процесс.