Planning разделение приложений

По умолчанию , при создании приложений Planning предлагается на выбор определить количество используемых баз – от одного до четырех (workforce), и зачастую у администратора приложений, встает вопрос сколько баз использовать в приложении – одну, две, три или четыре, для того что бы разделить приложение по типам используемых метаданных, по бюджетным процессам и т.д.

Такой подход к проектированию бюджетных моделей в Hyperion Planning оправдывает себя так как позволяет :

1. сократить размер базы данных
2. оперировать в формах ввода данных только актуальными метаданными, без использования «лишних» направлений
3. сократить время расчета бизнес правил (калк скриптов)
4. повысить эффективность разработки

Но все выше перечисленные плюсы перечеркиваются ограничениями накладываемыми физической реализацией алгоритма работы с базами данных, а именно:

1. все базы данных (кубы) работают в одном процессе,
2. все события работы баз данных пишутся в файл лога приложения
3. для 32 bit версии сервера EssBase накладывается ограничения на размер выделяемой памяти – (2gb) на приложение
4. в случае аварийного завершения работы одного из кубов, перезапускаются все базы данных в приложении

Поэтому, разработчики для больших приложений используют правило одно приложение Planning -> одна база данных в приложении essbase. Такой подход позволяет получить все плюсы от разделения, избежав ограничений EssBase, добавляя возможность разнести базы EssBase (и при желании сервер приложений Planing’a) на разные машины.