Все каментарии не читал, но практические мысли на эту тему есть.

Вопрос: подсчитать средний остаток за период.
Допустим что всех товаров.

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

Считаем во 2-ю табличку остатки на утро каждого дня начиная от остатков на начало периода. Расчет производить по собранной таблице движения на каждый день от предыдущего.

делай 3. находим средний остаток.
Кол-во измерений в табличках надеюсь досточно ясно.
Вопрос быстродействия не должен стоят очень остро.
На практике, имея витрину группированного движения расчет, который использует расчет остатков на каждый день длится на табличке в 10 млн. около 20-45 секунд, MySQL 5.0, машинка средняя П2,4 1 Гб мозгов.

Совет для различного рода писателей товарных движений - ведите регистры текущего состояния, тогда расчеты интересующих состояний будут работать одинаково быстро и через 1 и через 2 года.

backfire Валентин КСовет для различного рода писателей товарных движений - ведите регистры текущего состояния, тогда расчеты интересующих состояний будут работать одинаково быстро и через 1 и через 2 года.
А нельзя ли чуть подробнее. Что вы имеете ввиду?
Регистры текущего состояния - например сколько товара в текущих момент при проведении всех строчек документов. Это остаток на сегодня с учетом сегодня и пр., т.е. если протянуть все движение - то должна быть такая же цифра остатка товара.

backfire Валентин КВсе каментарии не читал, но практические мысли на эту тему есть.
Вопрос: подсчитать средний остаток за период.
Допустим что всех товаров.
Лучше это сделать скриптом запросов либо хп.
1 извлекаем суммы движения товаров в разрезе товаров, складов, приводя к одной е.и. в отдельную табличку.
Считаем во 2-ю табличку остатки на утро каждого дня начиная от остатков на начало периода. Расчет производить по собранной таблице движения на каждый день от предыдущего.
делай 3. находим средний остаток.
Кол-во измерений в табличках надеюсь досточно ясно.
Вопрос быстродействия не должен стоят очень остро.
На практике, имея витрину группированного движения расчет, который использует расчет остатков на каждый день длится на табличке в 10 млн. около 20-45 секунд, MySQL 5.0, машинка средняя П2,4 1 Гб мозгов.
10 миллионов - это в движений? За какой период времени?
скажите лучше сколько у вас не нулевых (товар, склад) на день?
В день около 25 тыс строк движения, т.е. приход, расход, передача, списание и пр. не документов, а позиций товара в первичных документах.
табличка движения где-то 25 млн. записей, группированных около 10 млн. на витрине.
Подобный расчет остатков используется для расчета нулевых дней для каждой позиции товара товара.

backfire Валентин К backfire10 миллионов - это в движений? За какой период времени?
скажите лучше сколько у вас не нулевых (товар, склад) на день?
В день около 25 тыс строк движения, т.е. приход, расход, передача, списание и пр. не документов, а позиций товара в первичных документах.
табличка движения где-то 25 млн. записей, группированных около 10 млн. на витрине.
Подобный расчет остатков используется для расчета нулевых дней для каждой позиции товара товара.

А на второй вопрос о количестве записей в таблицу отстатков ответите?
В таблице остатков - текущее состояние остатков, а таблицы остатков на день вообще нет, все расчитывается на лету "поворотом" таблиц.

backfire Валентин КВ таблице остатков - текущее состояние остатков, а таблицы остатков на день вообще нет, все расчитывается на лету "поворотом" таблиц.


А как же ваше же сообщение.

Валентин КСчитаем во 2-ю табличку остатки на утро каждого дня начиная от остатков на начало периода. Расчет производить по собранной таблице движения на каждый день от предыдущего.

Как это понимать?
так и понимать, я же написал - считается !!!, эта табличка создается в скрипте как результирующая в темпорари, я не знаю сколько в ней записей, просто перемножается кол-во позиций на кол-во дней, примерно за месяц 3000*30=90000 записей, вот собственно и расчет :)

Валеккороче человек предлагает делать таблицу остатков на каждый день
Уважаемые комрады.
Ваш что заклинило? зачем считать остатки на каждый день каждый день и это хранить?
Зачем хранить постоянно табличку остатков на каждый день? ничего я такого не предлагал.
Я показал реальный подход к расчетам, а не призываю к накомлению в базе данных-мусора.
Если нужно сделать отчет, тогда перед извлечением результатов отчета прогоняем скрипт, в котором все считаем во временных табличках и отдаем пользователю в результатах.
Вообще для быстрых расчетов есть отдельные подходы, которые оправдали себя на практике ускорением расчетов на порядок.
Смысл состоит в том, что для того, чтобы рассчитать сложный аналитический отчет нужно его рассчитать, а не парится установкой вских мега-OLAP серверов.
Проектировка DWH вообще проста. Помните комрады про шкалу - дата. Далее все быстро и просто.
К сожалению я не веду курсов по проектированию высокоскоростных структур данных.

backfire Валеккороче человек предлагает делать таблицу остатков на каждый день

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