авторВ случае с MS SQL/ASA/ASE все что вы теряете при разделении системы это DRI - так что смысл есть только если вы не планируете высокую связность этих модулей.
Я бы не ставил ASA в одну категорию с MSSQL и ASE. MSSQL и ASE могут довольно таки эффективно обрабатывать несколько БД на одном сервере, нормально оптимизируя запросы к данным различных БД, учитывая индексы и статистику. В ASA можно грузить на один сервер несколько БД, но обрабатывать он их будет автономно, т.е. каждая БД будет подключаться как внешний Remote Server и соотвествующе оптимизатор запросов не сможет создать такой же эффективный план, как у MSSQL и ASE. Я бы в ASA не рекомендовал такое делать. Единственное, когда разделение данных по разным БД наверное там имеет смысл, когда выделяется некая уже неизменяемая информация в архивную сжатую БД для работы в режиме только-чтение. Это улучшает производительность запросов за счет значительного уменьшения размеров БД (распаковать нужные страницы в памяти всегда быстрее, чем читать их с носителя), плюс так как ASA не требует постоянного подключения к удаленным серверам, вполне реально организовать хранение таких БД-архивов на сьемных носителях (те же CDROM, DVD и т.д.).

авторИнтересно а в чем смысл такой логики ASA?
Ну думаю это особенности архитектуры ASA. Изначально она все таки позиционировалась как встроенная СУБД или как Workgroup. Плюс она всегда позиционировалась как легкая в установке, не требующая никакого администрирования, независимая от используемого железа и обьемов СУБД. Из версии к версии разработчики ASA продолжают двигаться в этом направлении и если посмотреть на тот же оптимизатор запросов в современной ASA, то явно видны его развития в сторону максимального упрощения написания запросов (те же KEY JOIN, виртуальные вьюверы, иерархические запросы, повторное использование выражений в виде алиасов, добавление в UPDATE сортировки ORDER BY, привязка БД к текущим характеристикам железа, виртуальные индексы, перестройка таблицы в онлайн и т.д.). Проектировщик, правильно проектируя структуру БД и пользуясь общими рекомендациями правил оптимизации в написании запросов, благодаря самой архитектуре ASA будет для любого железа и используемых обьемов данных на автопилоте получать довольно неплохие планы запросов (конечно не на 100%).

Поэтому разработчики ASA и сделали БД максимально автономной - если в MSSQL и ASE есть БД Master, в которых и храняться характеристики сервера ( те же пользователи и группы), то в ASA все в БД. Это и хорошо, например нет геммора между переносами БД между различными серверами - достаточно ее просто скопировать и подцепить к нужному серверу, но и плохо, особенно как раз в случае, когда необходимо данные и логику растащить по нескольким БД. С учетом того, что ASA еще позиционируется как СУБД для мобильных устройств, думаю политика в данном случае правильная - БД Master на мобилах совсем не к чему :)

Вернемься к вопросу топика, СУБД наверное все таки лучше обсуждать в соотвествующих форумах.

Лично я считаю, что если задача должна крутиться на одном сервере, то смысла бить на разные БД нет - затраты будут больше, чем обоснованные плюсы. Единственное, в чем наверное есть смысл выносить в отдельную БД - это статичные или с централизованным добавлением информации справочники, без возможности изменения или удаления информации, которые для остальных БД будут считаться, как справочная информация только для чтения.