Собственно, не только совет нужен, а в целом, вектор направления усилий не совсем ясен.
Ситуация:
2 года назад сваял на SQL несколько табличек, очень по назначению похожих на витрину для остатков (дата, филиал, товар, на начало, 6 видов движения, на конец + все это в суммах). + ETL для этого. Сначала была табличка остатков и движения за месяц, потом 2-я табличка хранила за каждый день и при загрузке данных расчитывалась первая. За это время логисты успели наваять кучу приблуд, которые тянут эти таблички прямо из SQL. НИКАКОГО OLAP не было.

Сейчас есть совершенно новый поток данных и заходелось сделать еще одну витрину остатков с целью вывода в аналитическое приложение и ухода от унаследованных первых 2 табличек.
Объем данных не слабый - около 10 тыс товаров (рабочих - до 3), 300 складов, движение по 700 тыс. товарных операций в месяц.

Видится 2 варианта реализации:
1) "тупо в лоб" Делаем табличку с расчитанным TSQL остатком на каждый день. Тем же TSQL заполняем (для совместимости) унаследованные таблички. Сверху вешаем куб на новую табличку. Считал, что за месяц около 2 мил. записей, а с ходу появится 25 млн за весь период. Работает по 30 минут только на расчете остатков для 3 табличек.

2) "умно, но труднее" Делаем табличку с остатками, лежащими в первом дне, и только оборотами за месяц на каждый день (практически идеально для моей схемы в хранилище). Делаем куб, в котором мера остатка - расчитываемая из начальных +- обороты. Вместо унаследованных табличек пишем view с OPENQUERY к кубу (таким образом их не надо будет рассчитывать). Записей должно быть меньше раза в 3, чем в первом случае. Работает 5 минут над расчетом минут над расчетом данных для витрины.

Ограничения: Доступ к данным после загрузки должен появиться как можно быстрее (максимум через 30 минут после начала импорта данных). Импорт происходит раз в день, но около 9-10 утра. . Потери производительности на запросах к унаследнованным таблицам быть не должно ( а так туча Group by и т.д.)

P.S. В данном случае рассматривать только MS AS 2K + ProClarity. В качестве примечания буду рад узнать как это MSTR было бы лучьше подсунуть.

Спасибо !

конечно спасибо, но:
to Jimmy:
Читаем ограничения - пакеты появляются утром и до 10-11 должны уже лежать в витринах или кубах. Процессы такие, что делать..
2-х проц П4, сказевые винты, 1 Г, вообщем достаточно быстрый
кластерные есть, но не по сумме, есно, на суррогатных ключах места и времени данных, повторений около 200.
Нельзя ли конкретнее об " то оперативные данные можно юзать с агрегатами, а для архивных - расчитывать "на лету" - как делать в принципе ?

to Гликоген:
Это почему ? расчет остатков на день по складу и номенклатуре всего лишь операция с максимум 30 слагаемыми. В постах встречал и такие реализации.
про "ETL DecisionStream" огромное спасибо, если Вы еще напишете где 20-50 штук баксов на него взять, цены совету не будет.

Я тоже думаю, что так логичнее, но хотелось бы узнать мнение того, кто такое на MS AS сделал.

Вот !. истина уже рядом
Я как раз ссылался на посты г-на Иванова, и как раз есть табличка остатков и табличка движения, более того, sp делаю простой вид движения - income и outgo

to backfire:
А как бы к практической стороне подойти ?. не жалко приватно кинуть копии экрана с макетом кубов и формулы мер ?
Или с пивом бежать из Одессы ? ;-)

Ctrl-Break !
Сенсеи

Трудно удержаться
to Jimmy:
Тихо намекну, что OLTP система остатки на каждый день как правило не хранят, а хранят текущий, что большая разница.