Проблема с которой сталкивались фактически все :))
Интересует оптимальный путь решения (параметр оптимизации -- скорость ).
Пока ничего лучше чем табличка с учетом движений и materialized view`ы для выборки остатков по аналитике и по датам.
Пример:
Основная таблица -- хранит все движения по всем разрезам аналитики (фирма, склад, товар, дата движения) + поле количество (+ поступление - расход)
TABLE ArticleTraffic(
ID_ArticleTraffic NUMBER {PK etc.}
ID_Firm NUMBER {FK etc.}
ID_StoreHouse NUMBER {FK etc.}
ID_Article NUMBER {FK etc.}
DataTraffic DATE
Value NUMBER )

Соответственно имеем кучку вьюшек типа {Фирма,Дата,Остаток} || {Фирма,Товар,Дата,Остаток} и т.д.
Естественно, что прямого обращения и к таблице и к вьюшкам не будет -- только через ХП.
Интересующие платформы: ORACLE & MS SQL 2000
Интересует все что касается опыта разработки подобных систем и увеличения их быстродействия.

2 Deosfen:
1С знаю прилично. Не нравиться схема -- 2 (две) таблицы: 1 -- движения (аналогично описанному выше), 2-ая -- остатки. Замечу, что для dbf-варианта иного выхода пожалуй нет, но аналогично реализовано и для SQL-версии. Вариант с вьюшками считаю более правильным -- аргумент "за" -- операция пересчета остатков в 1С -- это просто песня. :)
Интересует:
а) статистика по скорости при аналогичных или близких схемах
б) другие варинты решения этой же задачи

Характеристики базы
Фирмы -- 3-10 штук
Склады -- 1-20
Товары -- до 50`000 наименований
Пользователи -- 5-30 одновременно, не более 20% -- "отчетники", остальные OLTP