Собственно, не только совет нужен, а в целом, вектор направления усилий не совсем ясен.
Ситуация:
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 система остатки на каждый день как правило не хранят, а хранят текущий, что большая разница.

Не надоело портить посты на тему ?
Хорошо бы модератору сделать типо форум "Чай с лимоном" как на forum.nobat.ru
Также не понял - кто-то пользуется openquery к кубику из TSQL для работы ?

to backfire: Мне показалось, что стоит подождать якись прикладов (примеров по приватной почте).жду.. спасибо..

Баста портить мою тему ! ;-)
А денег мало, конечно, особенно для Москвы. Я примерно на таких условиях ищу в Одессе (Украина) - если кто прочтет - обращайтесь !

Меня в таком же направлении backfire "толкнул" Я думаю, что оно верно, пока делаю, посмотрим.. Хотя такой подход уже озвучивался, вероятно надо было просто сказать, что оно так работает. А дальше как в том фильме - "вижу цель, не вижу препятствий" ;-)
C расчетом на уровне СУБД большей частью беспокоят остатки без движения, которые все равно приходится вставлять на каждый день и, конечно, объем. Если время формирования витрины остатков на каждый мембер измерений можно перенести на MS AS, который его "спрячет" за увеличение на 1-3 сек времени отклика, то это уже хорошо..