На мой взгляд WriteBack и RealTime OLAP предназначены для решения разных проблем, поэтому сравнивать их лоб в лоб не совсем корректно.

Далее комментарии к сравнительной таблице backfire:

> При решении подобной задачи, мною были рассмотрены 2 альтернативы - "real-time" ROLAP и write back-enabled MOLAP (хотя в нем WriteBack - Partition - ROLAP). Наложенное ограничение - MS AS Standard Edidtion (Enterprise Edition сильно догоро).

Real-time OLAP разрешен только в Enterprise Edition. Смотры по ссылке
http://www.microsoft.com/sql/evaluation/features/compserv.asp

Поэтому в рамках наложенных ограничений автоматически остается только WriteBack :)

> - Добавление новых элементов в измевения требует репроцессинга куба.

Добавление новых элементов в измевения требует только Incremental Processing измерения а не куба. Не очень понятно почему это стоит как минус для WriteBack, поскольку это не имеет прямого к нему отношения. В случае real time olap все то же самое.

> - Данные находящиеся во WriteBack - Partition, можно конвертировать в MOLAP, но это доступно только Enterprise Edition. В Standart Edition мы были бы вынуждены тянуть эти данные в таблицу фактов, чтобы изменения перекочевали в MOLAP.

Я не знал что конвертирование WriteBack Partition в MOLAP доступно только в Enterprise Edition. Во всяком случае это четко не обговорено
http://www.microsoft.com/sql/evaluation/features/compserv.asp
UI Analysis Manager реализует это довольно просто: Создать новую partition - и указать ей writeback table как fact table. Отпроцессить и сделать Merge с основной.

> -производительность на чтение (MDX запросы) в начале эксплуатации может проигрывать MOLAP c Write-Back.

Мне кажется, что это довольно серьезный аргумент. Если нет много Partitions (т.к. предполагается Standard Edition), то получается что единственная Partition в кубе будет ROLAP 0% aggregations. Производительность такого куба будет значительно уступать MOLAP кубу с хорошо определенными aggregations.

> Optimistic Locking при внесении изменений в таблицу фактов позволяет достить выокой степени Concurrency, в то время как Write-Back предполагает явное использование транзакций на уровне ADOMD.

Хочу заметить, что транзакции в OLEDB (а значит и в ADOMD) в Analysis Services в отличие от SQL Server не делают implicit table lock. Т.е. может быть несколько открытых транзакций на один и тот же куб и они не будут никак друг другу мешать, во всяком случае до момента Commit, которые сериализуются.

> kotorii dostigaetsya logikoi prilozheniya.
> posle izmenenii v SQL DB, na ROLAP cubike prosto delaetsya
>
> DSO.Cube.Process(DSO.ProcessTypes.processSuspend);
> DSO.Cube.Process(DSO.ProcessTypes.processResume);
>
> i delo v shlyape.

Вообще говоря, чтобы иметь консистентные данные в кубе, правильный порядок операций такой:

DSO.Cube.Process(DSO.ProcessTypes.processSuspend);
Изменения в SQL DB, Commit Trans in SQL DB
DSO.Cube.Process(DSO.ProcessTypes.processResume);

Это гарантирует что пока данные в ROLAP SQL DB меняются, пользователи куба не получат промежуточных результатов.

Но это хорошо что вы упомянули DSO, а то я забыл самый главный недостаток "real-time" ROLAP по сравнению с Writeback: Первый требует административных привелегий (как и любая операция с DSO), в то время как Writeback требует только Write access к кубу. Не говоря уже о том, что Writeback прячет от пользователя всю сложность mapping из обьектов DSO в таблицы и поля реляционной базы данных.

> Ya tolko hotel pokazat, chto RealTime OLAP v enkotorih sluchayah pomogaet
> spravisya s zadachami, dlya kotorih prednaznachen WriteBack, luchshe samogo WriteBack

В целом я с этим не согласен (смотри доводы выше), хотя допускаю что в некоторых случаях "real-time" будет ненамного хуже Writeback.

> Ya tozhe snachalya poproboval deistvovat soglasno BOL, no "nastupil na grabli" s
> suschestvuyuschimi ADOMD konnektami na etot kub - myagko govorya,
> ne stabilno rabotaet, a po russki "glyuchit".

Не очень понимаю что Вы имеете в виду. Возможно ситуацию когда после incremental processing изменяется количество уровней в parent-child измерении ?