ВМоисеев
Все зависит от задачи и типа доступа. Для локальных клиентов можно и час поставить, на удаленных клиентов и 5-10 минут, чтобы БД долго не держала отвалившихся по удаленной сети клиентов. При большом кол-ве коннектов можно и вообще не держать постоянно сессию активной. Ограничение для ASA - на каждый коннект тратиться 4 кб ресурсов. Я правда не очень понимаю, чем так страшно большое кол-во коннектов. Вот если они все реально тяжелые запросы начнут выполнять одновременно, тогда да - страшно, однако здесь уже не с ASA нужно сравнивать, а с Oracle, так как он побольше настроек балансировки нагрузок имеет. Но чем тут многозвенка помочь может ?

MainFrame1. Центарлизованные хранилища - это совершенно иной способ интеграции, который абсолютно для других задач, а не наших. Задачи с релаьным временем с хранилищами не работают
Согласен.

MainFrame2. что имеется в виду под удаленными серверами не понятно
Механизм Remote Server и прокси-обьекты. Если сервера различных СУБД находятся в зоне прямой видимости, то они спокойно могут между собой общаться, видеть таблицы, вызывать ХП, без какого либо дополнительного ПО.


MainFrame3. веб-службы (и SOAP - это же одно и тоже) - это и есть серверы приложений - , которые релаимзуют интеграцию. Это отдельный слой, а как имнено он реализован - веб-служьбами, приложениями, сервисами и т.п. не имеет значения.
...
Еще раз - веб-службы - эт о отдельный слой. Можно и на COM делать, если у вас только Windows - у нас не так. Мне кажется , вы почему-то сичтате веб-службы частью СУБД.
Я не считаю. Веб-службы и есть часть СУБД ASA 9, которая может работать как веб-сервер и осуществляет полноценную поддержку собственно описанных на WatcomSQL веб-служб и доступ к сторонним веб-службам. Пара строчек кода и мы прямо с БД всегда имеем курс валют с ЦБ или же собственную ХП обвязываем как SOAP процедуру и позволяет внешним клиентам по тому же 80-му порту ее вызывать и получать данные (иногда хорошая замена Remote Server). Я не спорю, что кроме ASA по моим сведениям пока никто не имеет такой интегрированной и легкой поддержки веб-служб, но ... в том же MSSQL2005 я думаю эмулировать ее через встроенный C# не будет предоставлять таких уж больших трудностей.

MainFrameНо не понятно Ваше предолжение. как удаленные серверы помогут в решении проблем поддержки в актулаьн6ом состоянии порядка 15 тыс. пользователей, когда 5 тыс обновляется каждый год ? У нас учетные записи создаются автоматически и права им назначаются автоматически. И соответсвенно ресурсы им доступные актуализируются автоматически и при измении ресурсов парва уже созданные меняюися автоматически. Но создавать 15 тыс. пользователей в базе данных ..Да и по поводу никто не напрягается ... если человек нормально работает, то напрягается - хоть одна база , хоть 10 тыс.
Гм, а чем плохо создать сколько нужно групп прав доступа и уже по этим группам создавать в БД 15 000 пользователей ? Так же при назначении пользователю нужной группы (групп) ему будут автоматически присвоены все нужные права, при изменении грантов в группе всем пользователям этой группы они так же автоматом будут изменены. Дополнительную защиту, выходящую за рамки грантов СУБД, элементарно реализовать через ХП и триггера.
Для удаленных БД, связанных репликацией, можно не напрягаясь организовать репликацию пользователей между всеми БД (у меня так и сделано, вплоть до изменении пользователем пароля в одной БД, он автоматом меняется на его логин в других БД, так что этот пользователь, даже уехав в самый удаленный офис, спокойно войдет в их БД под своим логином и новым паролем и имея достаточно прав доступа к информации этого узла, сможет работать). Однако для "смешанных" БД разных производителей, организовывать все придется через Remote Server, написав те же ХП, через которые создаются пользователи и вызываются ХП удаленных серверов для проведения аналогичных операций (да и по любому придется писать ХП, кто же даст обычному логину пользователя, пусть и администратора, полные права DBA, вся логика пользователя-администратора будет заложена в соотвествующие ХП, которые и будут разрешаться на выполнение таким администраторам, сами они не смогут не имея прав DBA сделать что нибудь выходящее за логику, предусмотренную разработчиками БД).