I dont knowКак есть TRUE? Зараннее благодарен.
Будьте уверены, что все велосипедостроители работают с базой от имени одного пользователя. Как же true - вопрос, вообще говоря, интересный. Я бы сказал, что, например, для сайта публичной библиотеки и для корпоративной информационной системы true решения будут изрядно разными :)

Во-первых, стоит отметить, что правильным для "серьёзных систем" была бы аутентификация и на сервере приложений, и в СУБД через LDAP. Во-вторых, для "серьёзных систем" пожалуй что нет конкурентов предлагаемой Oracle схеме с proxy users. Суть этой схемы: application server коннектится к СУБД под "своими" пользователем-паролем. Далее, когда требуется, application server говорит СУБД: а теперь я побуду Васей - и после этого работает с СУБД "от имени и по поручению Васи", используя его роли, имея его права на доступ итп.

shadenПо-идее, нужна тогда только одна лицензия на этого пользователя
По чьей идее?

По идее, нужно читать условия лицензирования СУБД. Можете быть уверены, что там этот вопрос специально оговорен, равно как и вопрос выставления разработанного софта в интернет с потенциально неограниченным количеством пользователей.

HauerКак вы там технически заходите в БД, их мало волнует. Им интересно, сколько реально одновременных пользователей работает с БД.
Ну в общем-то, я их даже вполне понимаю.

I dont knowТ.е как я понял должно быть две "базы" пользователей - одна на сервере, и вторая на самом сервере приложений.
Я бы сказал, это на две больше, чем нужно

I dont knowА какой смысл серверу приложений "прыгать" от пользователя к пользователю(теперь я побуду Васей, Петей, Джорджем...).
А какой смысл вообще иметь разных пользователей (Васю, Петю, Джорджа)? Смысл в том, что у них разные права на операции, разные ограничения видимых данных и т. д. и т. п.

I dont knowА если к серверу приложений подключаются десятки-сотни пользователей,
Маловато будет. Десятки-сотни пользователей разумнее обслуживать клиент-сервером. Сервер приложений целесообразен для тысяч, скорее даже десятков тысяч пользователей.

I dont knowне замучается сервер "прыгать"?
Куда меньше, чем замучается в альтернативных решениях.

iscrafmна чем основан такой вывод?
На сочетании нескольких факторов. Сколько пользователей нормально/плохо тянут СУБД, сколько стоит дополнительный геморрой разработки и поддержки, когда система проявляет склонность к распределённости и "категорически неБДшному" функционалу итп. Это не вывод, это эвристика.

I dont know1) "Сервера" должны взаимодействовать друг с другом
1. Что за сервера? Какие у каждого функции, почему их обязательно несколько?
2. А зачем для взаимодействия серверов трёхзвенка?

I dont know2) Должно быть несколько интерфейсов к системе, например linux, win и web версия...
Я понимаю, чем трёхзвенка может осложнить решение этой задачи. А чем она её упростит? Бизнес-логика уже не помещается в клиенте?

I dont knowПонимаю что можно взять какой-либо кросплатформенный тулкит и наваять по принципу клиент-сервер, но всё-же...
Вы связываете тёплое с мягким, имхо. Вариабельность клиентской платформы никак не связана с количеством звеньев сверх одного. Кроссплатформенные тулкиты тут в общем-то не при чём, хотя для таких требований естественный выбор - взять яву и нарисовать одно приложение с двумя-трёмя "мордами".

I dont knowВот тут возникает ещё один вопрос, как клиентскому приложению взаимодействовать с "сервером"
Ну, пока что непонятно, зачем вообще нужен "сервер". Клиентское приложение вполне может взаимодействовать с СУБД по стандартному, отработанному и кроссплатформенному протоколу этой СУБД. Если же таки делать трёхзвенку, то вариантов фактически три:

Использовать единообразную технологию для всех случаев (ту же яву) и соответственно любой реализованный в ней протокол

Использовать простой стандартный протокол, реализованный для всего (скажем, xml-rpc), сделав к нему нужную высокоуровневую оболочку

Использовать что-нибудь экзотическое-недоделанное типа CORBA, приплясывая с кучей бубнов.

I dont knowТакие вот мыслишки, поэтому и спрашиваю, раз клиент будет работать с "сервером", то как же самому серверу цепляться к БД. :)
Это совершенно отдельный вопрос, ответ на который в общем случае уже дан, а в необщем не хватает информации.

I dont knowПопробую обрисовать ситуацию, надеюсь ход мыслей будет понятен, скорректируйте, если что не так
Ход мыслей понятен и ожидаем, но спорно (чтобы не говорить "не так") практически всё.

В первую очередь, стоит всерьёз оценить, нужно ли уходить от одной базы. Произнесены только два слова, которые это оправдывают - территориальная распределённость. Тут надо оценивать, какие предполагаются каналы, сколько и как подключённых пользователей, каковы будут показатели по траффику и скорости работы. Если можно нормально остаться на одной базе - имеет смысл в N^2 раз сократить себе геморрой.

Далее, для связи нескольких баз не нужна никакая "сторонняя программа". Для этого нужна либо настроенная репликация, давно реализованная для всех СУБД, либо доступ к удалённым базам - не знаю, везде ли он реализован, но скорее всего именно так.

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

По поводу гибкости: да, конечно, разделение баз позволяет гибко тасовать их между физическими железяками и географическими расположениями. Но нужно всерьёз оценить, стоит ли такая гибкость дополнительных проблем. И стоит помнить, что хорошее железо чаще всего стоит значительно дешевле, нежели дополнительный труд программистов и администраторов.

I dont knowавторБизнес-логика уже не помещается в клиенте?
Предполагается наоборот, бизнес логика будет храниться на сервере БД,
Это была шутка с намёком. При реализации логики в клиенте написать несколько "морд" клиента действительно тяжело и возникает "естественное" желание вынести её из клиента в третье звено. При реализации же логики в СУБД несколько клиентов сводятся к нескольким "мордам" одной и той же логики, и реализация в этом случае промежуточного звена - лишние трудозатраты.

I dont knowнапример головной офис запрашивает у пподразделения отчёт, сам отчёт-его select находится на сервере подразделения, а СДО головного офиса делегирована возможность его запускать, в головном просто нажимают кнопочку "Отчёт", СДО головного даёт запрос СДО подразделения - "Дай мне отчёт", СДО подразделения даёт запрос своей БД, та результат выборки, СДО подразделения эти результаты отправляет на СДО головного... там глядят... всё радуются... выдохнули)
Угу, о чём и речь. Программист сидит и пишет для СДО реализацию того, что делается в СУБД примерно за 30 секунд. А когда (что обычно) головной офис захочет увидеть данные всех подразделений в едином отчёте - обрадованный программист вообще на месяц уйдёт реализовывать в СДО механизм слияния.

I dont knowТут имхо основным плюсом такого подхода как раз и является гибкость.
Безусловно. И ключевой вопрос, в котором программисты часто принимают плохое решение - оценка стоимости и нужности гибкости, правильное размещение границы между оправданной и излишней гибкостью. Прошу прощения за не совсем деликатный пример, но, выбирая себе автомобиль за свои деньги, Вы будете долго думать, оценивать варианты и наконец, что-то решите. И можно быть уверенным, что Вы не потребуете от автомобиля гибкости в варианте "мне может потребоваться отвезти на дачу пять-десять кубов песка, может потребоваться проскальзывать между машинами в пробке и может потребоваться встречать деловых партнёров на представительском классе". А вот проектируя софт за чужие деньги, к сожалению, подобное желание гибкости встречается. Потому как закладывать такую "гибкость" легче и интереснее, нежели продумывать, что на самом деле может понадобиться.

I dont knowЕщё есть такая штука как например различие бизнес процессов
Есть. И оно никак не влечёт за собой необходимость разных баз. В моей текущей задаче так вообще, для некоторых значимых моментов каждый год свои настройки, потому как внутри организации всё меняется.

I dont knowи некоторое различие структуры сущностей.
А такой штуки нет. Вернее, опыт работы с ней эффективно учит тому, что допускать её - себе дороже.

I dont knowКонечно, теоретически, можно все бизнес процессы привести к некому общему процессу,
И теоретически нельзя, и практически нельзя. Эту сказку начальство рассказывало мне ещё в 98-м году, и я уже тогда в неё не верил. Как вскоре оказалось - правильно не верил.

I dont knowЕсть также различие карточек документов, формально это одна и та же карточка документа(назовём её РКК), только в одной конторе в РКК 5 полей, а в другой 20,
Видимы, нужны и/или доступны 5 полей, а в другой - 20. Это совершенно стандартная задача, вскоре Вы обнаружите, что в одной и той же организации одному пользователю из этих 20 полей нужно показать 8, другому - 10, третьему - оставшиеся 6. Речь, конечно, идёт о полях, значимых с точки зрения бизнес-логики. Всякие custom memo - отдельный несложный вопрос.

I dont knowПоможет ли тут репликация? Если нет нужды держать синхронизированный набор данных, данные у каждого свои.
Репликация совершенно не означает необходимости одинаковой структуры. А вот попытка разрабатывать более-менее работающий софт за разумные деньги - означает. Я уже готов с интересом понаблюдать, как в Вашей схеме сервера будут передавать друг другу "отчёты" и особенно сливать данные из них при различии структур данных. И мне очень интересно, пытались ли Вы хотя бы оценить трудоёмкость тестирования вашего софта на 20 разных структурах БД. Также любопытно, как часто Вы проводили согласованное изменение (одинаковых) структур БД на десятке-другом серверов, сталкивались ли с допущенными ранее мелкими различиями и их влиянием на выполнение патчей, пробовали ли писать патчи так, чтобы они отработали на двадцати разных структурах.

I dont knowБудете смеяться, но от текущей системы примерно такое и требовалось,
Да нет, не буду. Ибо баян.

I dont knowможет изначально стоит заложить мерседес, чтобы потом проще было? Вот я к чему...
Не исключено, что это правильное решение. Но не менее вероятно, что, сидя с мерседесом, Вы обнаружите, что нужно было закладывать БелАЗ, вот я к чему. Чтобы было проще - и сейчас, и потом, и всегда - нужно хорошо думать и выбирать решение, соответствующее сегодняшним и завтрашним потребностям задачи. От Вас пока не прозвучало ничего, кроме неопределённой "гибкости", что стимулировало бы выбрать трёхзвенку.

Что вам нужно на самом деле? Да не знаю, и никто здесь не знает. Это нужно глубоко врубаться в задачу и много думать.

I dont knowНу почему нельзя? Наверно это зависит от самих бизнес-процессов,
Да потому, что это зависит от клиентов. Если ограничиться госструктурами, это реально - их бизнес-процессы зарегламентированы законами и инструкциями. А коммерческий клиент на фразу "у нас заложен вот такой бизнес-процесс, вы теперь будете так работать" говорит "нет, мы будем работать как я сказал, а вот купим ли вашу систему - зависит от того, поддерживает ли она наш бизнес-процесс". В итоге на свет появляются очень весёлые внедренческие решения, например, я на всю жизнь запомню одно внедрение OeBS, в котором то, что в реальности было химическим заводом (общая схема: с одного конца в здание входит труба газопровода, с другого - выходит, посередине оборудование, перерабатывающее этот газ) представлялось в системе как комбинация из трёх складов с прописанными бизнес-правилами перекладывания ТМЦ со склада на склад.

I dont knowавтори особенно сливать данные из них при различии структур данных
Структуры баз то как раз одинаковы... отличие может быть например в реквизитах справочника или в самих справочниках, в одной базе есть такой справочник, а в другой нет,
:)

I dont knowно в тоже время в нашем случае такие проблемы возникали в основном из-за отсутствия каких-либо автоматизированных средств для решения наших задач. ... и к тому-же в некоторые системы надо перенести эти изменения с учётом "местной" специфики ...
Пока что не изобрели искусственного интеллекта, способного модифицировать патч с учётом "местной" специфики. Автоматизация - дело хорошее, но в условиях добровольного зоопарка она не спасает. Спасает исключительно запинывание зоопарка в жёсткие рамки, когда "местная специфика" учитывается в предусмотренных для того местах, а всё остальное - общее.

I dont knowДумаю при наличии скажем хорошей среды администрирования проблем будет гораздо меньше.
(пожимая плечами) Почему Вы не взяли эту хорошую среду и не решили возникавшие проблемы? Или не написали свою хорошую?

Нет, я верю, что к тому были объективные причины. Вот только странно думать, что теперь вдруг "хорошая" откуда-то возьмётся :)

I dont knowНемного утрированно, c чем можно сравнить вариант с одной базой и вариант с несколькими: в первом случае это как коммунальная квартира, вроде у каждого свой уголок, но в целом бардак... Во втором же случае это жилой дом с квартирами, у каждого своя отдельная квартира и там он крутится как хочет не мешая другим. имхо.
В этой аналогии первый вариант стоит сравнить скорее с казармой: там могут жить десантники, танкисты и даже те и другие сразу, но любой офицер сходу разберётся, что к чему. Аналогию с жилым домом можно оставить, она хорошо иллюстрирует проблемы патчей: поставленная соседями железная дверь перекрывает доступ к общеподъездному автомату, в результате чего все сидят без света, а прочистка вентиляционной шахты брошенной туда гирей пробивает соседский холодильник (то и другое - реальные случаи).

I dont knowВ этом случае обобщающий вопрос: Несколько контор в одной базе, это вообще по фен-шую? :)
(пожимая плечами) А несколько подразделений одной конторы в одной базе - это вообще по фен-шую? А несколько сотрудников одного подразделения?

Cугубо имхо, данные, которые могут быть востребованы в одном запросе, заведомо феншуйно могут быть размещены в одной базе. Даже если заведомо не могут - такое размещение таки имеет некоторые плюсы. Тот же Oracle в своё время продвигал концепцию Virtual Private Database, суть которой в том, что в сервисе а-ля, например, mywordpress.com, создавать свою базу для каждого пользователя как-то глупо; вместо этого все работают с физически одной БД, но права пользователей выставлены так, что каждый видит только свои данные и общие справочники.