2 Володя:

PS. Совет если у вас серьезный ретейл, не связывайтесь с решениями на MS SQL 2000. Там серьезнейшие проблемы с работой на больших измерениях типа "Покупатели". Лучше MS SQL 2005 или таже Микростратегия.

В серьезном ретейле обычно бывают серьезные объемы данных. Микростратегия будет конкретно тормозить... К тому же MSTR не имеет функциональности OLAP, так что к теме топика она не относится.

2 незарег:

А знание предметной области у Вас имеется?
Рекомендую почитать ссылки на тему отраслевых решений для оптовой и розничной торговли:
http://www.programm-line.ru/solutions/branch/wholesale
http://www.programm-line.ru/solutions/branch/retail

2 незарег:

Более или менее, в Ваших ссылках в основном описание того что мы можем, а как это сделано нет
Можно где посмотреть реальную реализацию такой системы? Нужны примеры реализации в данной сфере. Или это ноухау каждого разработчика и посмотреть никак нельзя?

Посмотреть реальную реализацию можно, либо у кого-нибудь из заказчиков, где это внедрено (после согласования возможности проведения референс-визита с заказчиком), либо у разработчика на демо-примерах. Если интересно - обращайтесь.

2 Володя:

В MS AS 2005 картина другая. Там например спокойно живет измерение с десятком млн. пользователей сотового оператора.

В OLAP-кубе MS AS 2000 тоже можно хранить 10 миллионов пользователей сотового оператора. Хотя некоторые аналитические операции потребуют хорошего железа.
А что можно с этим измерением сделать в MS AS 2005? Можно ли например вывести его в боковик отчета в OLAP-клиенте, чтобы в отчете получилось 10 миллионов строк? А потом, выведя в колонки отчета несколько показателей, посчитать какое место в рейтинге занимает по каждому из показателей каждый пользователь?
И теоретический вопрос - как хранится такое измерение в MS AS 2005 - в многомерном или в реляционном формате?

В серьезном ретейле обычно бывают серьезные объемы данных. Микростратегия будет конкретно тормозить... К тому же MSTR не имеет функциональности OLAP, так что к теме топика она не относится.
Бездоказательно Ватсон. Тем более что ретейл фирменная фишка у Микростратегии. Не будем заводить что-то похожее на флей и рекламу. Ok?

Да, флейм заводить не хочется, хотя вопрос крайне интересный... И в недавнем OLAP Survey было сказано, что MSTR на приличных объемах БД имеет самую низкую производительность из всех популярных аналитических систем.

Почему-то в России у MSTR нет ни одного внедрения в серьезной рознице, об успешности которого был бы написан пресс-релиз. Например аптека 36 и 6 вроде как использует MSTR, но почему нет никакой информации о результатах внедрения? Отсюда напрашивается вывод, что для достижения нормальной производительности MSTR должно обрабатывать не терабайтные ХД, а килобайтные таблички с агрегатами, которые формируются хранимыми процедурами РСУБД.

2 MSTR_Fan:

Юра, мне кажется что у Вас MSTR висит на дартсе, и вы в свободное от работы время стреляете в неё из табельного оружия, правда? :)

Да нет, я бы никогда не тратил на это время. Хотя Дартс - игра неплохая :)

Сказать что MSTR имеет низкую производительность - это всё равно что сказать что SQL имеет низкую производительность. В каком окружении, на какой СУБД, какие объемы данных? Может стоит попробовать почитать про моделирование и performance tuning в современных СУБД? :)

Неужели мы наконец дошли до истины... Конечно, SQL имеет низкую производительность, когда речь идет об аналитических задачах. Поэтому и придумали OLAP.
SQL заточен на поддержку OLTP-систем, на выборку малого количества записей по индексам, или на инсерт-апдейт... А задачи просчета агрегатов на уровне РСУБД - это всегда долгие процессы. Уж лучше это время использовать для создания и/или обновления OLAP-кубов, в которых заведомо больше агрегатов, чем в реляционных таблицах с агрегатами. Да и в кубах есть интерактивность.
А оптимизация - хотя и дело хорошее, но увеличивает производительность не так уж значительно.
Я уж не говорю про случаи когда надо работать не с СУБД Оракл или Терадата на дорогом и мощном железе, а с текстовыми файлами...

А относительно тормозов MSTR в Retail, отсутствие внедрений... Вы конечно правы, в Retail MSTR значительно хуже Cognos! :)

Если без шуток, то про Cognos пишут довольно много пресс-релизов, там скрывать нечего.