MasterZivУ ASA немного другая идеология. На одном сервере (инстансе серверного процесса, не хосте, где размещается БД) может быть только одна база данных.
Поэтому для новой базы нужно запускать новый "сервер".

PS: Знатоки ASA, я правильно все изложил :))
Нет ;) На одном Engine может много БД крутиться. Поднимаются они или сразу при старте сервера, перечисляясь в командной строке запуска сервера, или же во время работы операторами START DATABASE и STOP DATABASE. Ограничением выступает только размер страницы БД - нельзя в ходе работы сервера поднять БД, у которой размер страницы больше, чем тот, который использовался при запуске сервера, который берется как максимальный размер страницы из указанных БД при запуске.

Идеология ASA в другом, в отличие от ASE: нет БД Master, в которой прописан список БД, присоединенных к серверу, каждая БД полностью автономна, т.е. свои логины, свои настройки и опции БД и т.д. Соответствующе в отличие от ASE нельзя в коде одной БД обратиться напрямую к обьектам другой БД, необходимо делать все равно Remote Server и работать с другой БД, работающей на том же сервере, как с удаленным сервером.

Плюсы и минусы такой архитектуры очевидны:
+ У БД нет привязки к серверу. Ее легко переносить с сервера на сервер (скопировал и запустил), не задумываясь например, о переносе пользователей.
+ Легко запускать множество независимых серверов с множеством БД. Каждый из серверов обладает своим кэшем и ресурсами, все БД на одном сервере разделяют общие ресурсы сервера. Я например, всегда разделяю сервера на боевые (рабочие) и тестовые (девелоперские), чтобы при падении сервера в девелоперской или тестовой БД, рабочий сервер продолжал работать. После прохождения всех тестовых проверок, скрипт изменений схемы БД уже запускается на боевой БД, которая если является консолидированной, дальше его по репликации рассылает по удаленным узлам.
- При такой архитектуре один проект разделять на несколько БД неудобно. Работа через Remote Server накладывает определенные ограничения, плюс, чтобы обратиться к обьектам другой БД придется создавать прокси-таблицы и прокси-ХП.
- Оптимизатор ничего не знает об обьектах другой БД. В MSSQL или ASE при выполнении запроса к обьектам разных БД при построении плана запроса будут сразу учитываться все обьекты, использоваться индексы и статистика. Для ASA это будет идти как полноценное выполнение запроса к удаленному серверу, то есть оптимизатор разложит запрос на доступ к родным и чужим обьектам, пошлет выполнение частей запроса к удаленному серверу, далее уже будет соединять с родными обьектами. Думаю понятно, что в ASA при выполнении запроса на несколько БД можно получить значительный проигрыш в скорости.

Соотвествующе, на ASA не выгодно разделять один проект на несколько БД. Должны быть очень веские причины. А если бы например у меня было несколько проектов, имеющих между собой общие таблицы, которые активно бы влияли на жизнь БД во всех проектах (то есть участвовали в запросах, ХП, триггерами изменяли другие таблицы в проекте), то я бы вообще наверное вынес бы эти общие таблицы в отдельную БД, эти же таблицы создал во всех проектах и через SQLRemote организовал бы подписку проектов на выделенную БД, как консолидированную. Получилось бы гораздо меньше кода, больше оптимизации и легче в управлении, чем если бы я пытался их сцепить через Remote Server.

White Owl,

Спасибо друг за ответ вместо меня. А то я уже ASA подзабывать стал, 17 версию и в глаза не видел :(

P.S. Хотя вот прямо сегодня как раз про ASA и вспоминал, глядя на NATURAL JOIN в Vertica и думая, что явно KEY JOIN как в ASA не помешал бы :)