2Birkhoff
Коллега, если вы работали с MS AS, то только патриотизм к инструментарию Oracle вас может удерживать на Express. :)
С выходом Юкона я думаю Oracle потеряет еще полрынка в BI. Уже без смайлика.

В MS AS можно использовать в качестве процедур UDF, довольно часто из них вызывают обычные SP из MS SQL. В Юконе будут хранимые процедуры для MS AS

Analysis Services “Yukon” introduces stored procedures to extend the capabilities provided by user defined functions (UDFs). A stored procedure can be written in any common language runtime programming language such as C++, VB or C. Stored procedures simplify database development and implementation by allowing common code to be developed once, stored in a single location, and reused in other stored procedures, calculations, and user queries.
There are two types of stored procedures:
• MDX function stored procedures are like any other MDX function, and provide a mechanism for easily extending the MDX language.
• Custom stored procedures perform tasks specific to an implementation such as cube processing or updating cells in a portion of the cube.
A stored procedure can be used to perform any task that a client application can perform.

На мой взгляд основные проблемы MDX в следующем.
1) Клиентское разрешение MDX запросов и как следствие провал производительности на крупных решениях для MS AS. Пендс (olapreport.com) называл MDX ахиллесовой пятой MS AS (в плане производительности). Однако данная проблема будет разрешения в Юконе

Calculations are centralized on the server. Analysis Services “Yukon”, by contrast with Analysis Services 2000, performs all calculations on the server. The advantages are significant: Clients have a zero footprint; the client-side cache is eliminated. Query performance for complex calculations is greatly improved.


2) "Как далеки декабристы были от народа". Основная проблема MS AS и MDX крайне слабая методическая поддержка разработчиков, местами складывается впечатление, что коллеги из MS находятся в башне из слоновой кости и делают отличный, но идеальный инструмент. В результате подавляющее большинство инженеров не знают как эффективно решать массу насущных бизнес-задач. Вспомним тот же накопительный остаток. Хотя местами есть отличные решения, хотя бы тоже Tutorial по MS AS. Тем не менее, специфика построений бизнес-решений под MS AS весьма плохо раскрыта, нет законченных и реалистичных бизнес-примеров. Вот и крутятся разработчики на Sales-кубах как вершине OLAP-творчества. Мало каким аналитикам даже в голову приходит, что в BI можно строить комплексные и самодостаточные DSS от верха до уровня среднего звена менеджеров. А примеры производственных OLAP-решений? Мне приходится этим сейчас заниматься, когда я скачал примеры OLAP-кубов для manufacturing с mirosoft.com я просто плакал. А ведь кто-то будет этому подражать!

Если говорить о планировании, я бы сказал что текущая реализация "write-back" в Oracle лучше чем в MS AS. Однако в любом случае это бюджетирование для кухарок. Мне приходилось руководить разработкой и внедрением 3х крупных систем для управления бюджетами CashFlow и Profit&Loss. Для крупных модулей бюджетирования (замечу модулей, а даже не систем) проблема занесения плановых данных полностью тривиальна. Сложность представляет разработка эвристических алгоритмов прогнозирования через тренды и главное пирамидальная система заявок/ТЭО с очень сложным workflow по утверждению.
Вывод: если не хотите халтурить, делайте нормальные документы и процедуры по workflow планирования в OLTP и их анализируйте в OLAP.

Однако решения для кухарок тоже востребованы. Они дешевы и просты во внедрении, но до Юкона мы их не производим. MS AS 2K тут фактически не работоспособен. А вот Юкон подает надежды и немалые.

Writeback

Enhancements to data writeback include a ten-fold performance improvement. The analytic application can write data back to an aggregate cell, and optionally perform allocation of the aggregate data to its underlying leaf data.

Real Time Business Intelligence

Data warehouses and Business Intelligence applications have traditionally used "aged" or high latency data – data refreshed monthly, weekly, or daily. Traditionalists will assert that real time BI is an oxymoron – strategic decisions should not need data that is more timely than daily at best. What these commentators are missing is that business intelligence should be pervasive throughout the enterprise, and not just deployed to a few analysts and executives for purely strategic and tactical decision-making. Operational business intelligence requires low latency data.
Analysis Services “Yukon” provides new processing options for operational business intelligence. In Analysis Services 2000, cubes – no matter their storage mode or partitioning strategy – were processed with a "Pull" model. An Analysis Services process was launched that looked for new information in the source database, processed and optionally storeed the detailed data, and computed and stored the aggregations.

2Mayday
Мне кажется, вы странно ставите вопрос. Типа в MS AS люди просят делать элементарные задачи, а вот увидев Oracle сразу рожают супертребования. На мой взгляд пользователю все равно как это будет реализовано, у него есть бизнес-потребности, а инструментарий вторичен и дело разработчика.

Насчет UDF согласен, потому мы и страрались их мало использовать, разве что для целей создания фильтров по security.

Насчет бюджетирования я именно это и предлагаю. В большинстве случаев более правильно вводить данные не через куб, а через документ. У нас сейчас идет схожий проект по постановке бюджетирования в крупнейшей в СНГ промышленной группе по производству сахара. Так вот, на разных предприятиях и заводах холдинга разные системы. В основном 1С и наш комплекс Ultra Project. Пользователю гораздо удобнее вводить данные через документ даже 1С, например он может его заполнить данными "на основании" и несколько пользователей могут работать над составлением одного бюджета. Более сложный пример с ТЭО для оптимизации бюджетов закупок. Там информации вводится много, в OLAP-кубе просто нет для них ячеек и средств обработки.
Это я к тому, что backfire возможно стоит написать на VB программу, в которую пользователь обычными формами может забить плановые данные и склетить эти данные данными из OLTP откуда берутся факты. В кубе это конечно проще и местами гибче, но вопрос для бизнеса правильно ли?

Потом пока writeback в MS AS нерабочий мне кажется делать на нем серьезные решения для клиента это подставлять клиента. Проблемы-то будут не только у разработчика, но и пользователей. Поэтому мы и ждем Юкона, ждать 2го квартала не так долго.

2Birkhoff
Мне кажется что вы только подтверждаете истину, что хороший внедренец важнее хороших продуктов. Уверен, вы легко нейтрализуете или обойдете большинство недостатков Oracle. В MS AS с этим сложнее, как видно по форуму даже квалифицированных инженеров есть дефицит, а с аналитиками еще сложнее. Вот и делают на MS AS убитые системы чаще, хотя сам продукт весьма неплох.

2Backfire
Выше я привел пример решения для компании с численностью персонала свыше 10000 человек, продающей на сотни млн. долларов в год и имеющей целый ряд заводов, причем производство сахара, как и любая биохимия, технологически довольно сложное (почти 40 тех. Стадий). Для примера у наших клиентов производящих кирпич или полиграфию это всего 3-5 тех. стадий. Как ни странно по техсложности производство сахара сравнимо с нефтепереработкой.
Однако даже не таких объемах мне кажется 1С в локальном филиале удачное решение, в центральном офисе должна быть система помощнее. Примерно также пошел наше МПС. В головке SAP, а на местах 1С и сделана XML-интеграция. Идеально? Нет. Плюсы есть? Есть. Надо просто взвешивать плюсы и минусы.

Я согласен с теми плюсами, которые вы приводите. Однако есть и оборотная сторона медали. Такая техника из-за своей гибкости не позволяет системе контролировать дисциплину бюджетирования (пользователь может сделать как захочет), что неприемлемо для многих наших клиентов. С точки зрения методологии бюджетирования, вы предлагаете не "крутой", а именно упрощенный вариант (хотя и гибкий). Поэтому VB тут инструмент адекватный задаче, по моему мнению.
В общем я предложил решение, вы считаете иначе и у вас есть свое обоснование своей позиции. Не вижу предмета для спора.

2backfire
Форум оборудован "Русской Виртуальной Клавиатурой", если можно воспользуйтесь, очень трудно читать траслит.
Я привел пример клиента не столько из рекламы (отметим не смотря на искушение я его не назвал, а это Бренд), сколько чтобы подчеркнуть сегмент применимости решения.
Поясню. Данные из 1С-сок филиалов стекаются в ЦО, где делается их консолидация и анализ. Стандартный подход. Единственно что, для особокрупных филиалов под 1С ставится и свой локальный OLAP, иначе 1С ложится на бок через 1 мес работы. Приходится базу чистить.

Обсуждение Oracle и MS AS и иже с ним ушло в отдельную ветку.