Ну так если интересно... У нас есть такой проект, команда 5 человек (из них 3 программиста, тестера, ....), живет около 3-х лет (сам проект). Почитать (правда не очень много, можно на сайте http://pbgroup.narod.ru).

Кратко: гибридная 3-х звенная схема, СУБД (ASE, ASA - а в принципе, что билдер поддерживает), EAS или Ягуар (кому как нравиться) и специально облегченный (почти тонкий клиент :)) ).

Система работает сейчас в 2-х режимах: 3-х звенка и локальный клиент с ASA. Сделано по причине большого числа филиалов и доп офисов. ASE & ASA выбраны по причине очень приятной синхронизации данных, небольшая надстройка над которой позволяет одному человеку поддерживать все филиалы из центра. Удобно...

Все модули в системе реализуются для ASE, а для ASA с очень небольшими доработками (уж поверьте мне) все идет просто на ура, что дает большой выигрыш - не надо тратить усилия на разработку отдельно филиального и центрального софта.

Ягуар в центре обеспечивает несколько основных и важных функций: масштабируемость нагрузки, автоматическая смена версий что немаловажно для развивающихся проектов, разграничение прав доступа (обычно это лежит на клиенте) ...

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

Все это крутилось по задачам автоматизации страховых компаний, чей бизнес постоянно меняется и на такую схему работы нас руководство просто вынудило перейти.

Еще интересная особенность нашей системы - это слабая зависимость от существующей схемы СУБД. Попробовали поднять небольшой пример с большой системы, которая писалась более 7 лет на Оракле на классическом клиент-сервере - вполне удовлетворительно, а с небольшими доработками вполне можно и продублировать старую систему.

Если интересно узнать больше, задавайте вопросы сюда, а еще лучше - дублируйте на почту pbgroup@mail.ru

TO: Black Savage

1. Филиалы расположены по всей РФ... Для связи с филиалами требуются каналы связи (хотя конечно можно и курьером с дискеткой - и такое было - 2 месяца дискетки возил :)) ). Каналы связи у нас - электронная почта. Но сразу предупреждаю - могут быть проблемы с потерей сообщений, лучше пользуйтесь ftp.
2. Через WEB-клиента пока система не работает, но по весьма прозаической причине - пока не требовалось. Тонкий клиент - свой собственный с обычным GUI-шным интерфейсом. Система вполне позволяет работать с браузером (все необходимое заложено), но есть несколько НО:
- WEB интерфейс сильно беднее функционально по сравнению со стандартным интерфейсом.
- клиент не стандартизирован, поэтому постоянные затраты на совместимость (наш админ категорически не хотел IE а требовал Netscape - административно проблему решать было невозможно в нашем случае) + увеличивается неразбериха с филиалами.
- при попытках реализовать "мощный" интерфейс - проблемы с производительностью - большой "лишней" информации по интерфейсу. Поэтому на мой взгляд, если нужен обязательно WEB то варианты следующие: свой клиент но через WEB, Java-плагин на сайте. Можно конечно воспользоваться фирменными сайбесовскими технологиями по генерации DW - но уж больно много доводки да и сильно прожорливые они...

3. По поводу on-line. Чистый он-лайн не требовался, да и слишком дорого. Мы использовали сайбесовскую схему репликации с требуемым в каждом узле периодом синхронизации. 5 минут - вполне нормально для оперативной обработки для наших пользователей. Реально у нас была точка с периодом синхронизации 2 раза в день (10 и 17 часов) и несколько раз в месяц они просили сисадмина провести принудительно (что делается быстро и просто). После года эксплуатации на вопрос - может чаще - отказались, говорят, что вполне устраивает все.

Необходимо учесть что он-лайн дает существенную нагрузку на центральный сервер (хотя схема репликации сайбеса очень неплохо сделана) и это не всегда приемлемо. Хотя можно сделать и чистый он-лай этому ничего не мешает...


Ну если что еще, пишите...

TO funikovyuri:

В принципе согласен, только есть несколько но:
- сложности с проектированием и отладкой компонент
- сложности оптимизации
- ну и еще по мелочи

Поэтому свой собственный опыт показал, что писать надо проще и понятнее, тогда и эффект появиться Тем более в плане транзакций у СП есть встроенные механизмы позволяющие упрощать обработчики компонент.

Вообще EAS имеет (на мой неискушенный взгляд) - один очень большой плюс: работа с DW. Что позволяет, используя возможности DW по максимуму, добиваться интересных решений.

ТО Black Savage:
1. Смотря в каком режиме клиент работает и в какой конфигурации. В самом упрощенном смысле схема выглядит следующим образом: на клиент передается пул коннектов к требуемым БД, в дальнейшем при открытии окна, при вызове процедуры запрашивается нужный - он активируется и проводится нужная операция. Поэтому основная схема работы и названа гибридной трехзвенкой :)). Сервер приложений отвечает за конфигурацию клиентской части да еще в режиме он-лайн. Он хранит и распределяет модули системы, права доступа.... По умолчанию клиент ничего "не умеет", кроме отображения, но "умеет" запрашивать информацию по модулям и их бизнес логику у компонент на сервере приолжения и ее отображать.

В свое время я реализовал чистую трехзвенную схему на тех же принципах, открывая пул компонент на СП, которые и держали коннекты, проводили требуемые изменения (все делалось на основе Get(Set)FullState DW) - но схема оказалась тяжелой и неэффективной. А такая гибридная схема весьма удобной как для разработчика, так и администратора и конечного пользователя. Во всяком случае - до сих пор живет

Очевидный плюс - разработка новых проектов или подсистем с нуля - прототип системы с "хорошим" наполнением появляется очень быстро. И работа с заказчиком уже ведется по горячему (что называется). Не тратится много времени на общие разговоры, все довольно быстро скатывается - "... ты пальцем ткни...". Единственный минус таких разработок - уж очень быстро клиенты во вкус входят и требуют все больше и больше :(.

2. Слабая зависимость не в смысле СУБД, а в смысле клиента. Просто мы столкнулись не единожды с некоторыми похожими разработками (от простой и удобной библиотеки компонент для разработки систем с нуля до серьезных систем, которые также очень много в себе содержат по функционалу и упрощают процесс разработки конкретной системы). Ну один пример я думаю всем известен - PFC.
Не претендуя на особенность, скажу только следующее - те задачи, которые требовались решить - довольно легко и быстро небольшими силами прототипировались а потом и реализовывались на нашей системе.
Конечно - проблема смены СУБД - везде актуальна, просто известные мне системы также довольно сильно настроены были на MS или Oracle. Мы старались по возможности реализовать систему, использующую в качестве СУБД практически любую известную (с которой Билдер можно заставить работать). Конечно - реалии могут быть не такими радужными, но меня весьма порадовал быстрый и легкий перевод части разработок под Oracle.

ТО Black Savage:
Прошу обратить внимание и на то, что сравнивать надо корректно сервера, а то у меня тут бул один случай, когда сравнивали ASA на однопроцессорной дохлой машине (плохонькой рабочей станции) с MS SQL на HP2000 c рейдом и кучей мозгов.
Уж очень часто ждут чудес без должного обеспечения :(. Сам с последними версиями ASA не работал, но наш сисадмин уверяет, что 9.х очень даже неплоха и вполне может тягаться с ASE по всем стандартным критериям, выдвигаемым к СУБД. Я даже не знаю, что Sybase будет дальше делать с двумя весьма похожими по характеристикам СУБД?
Лично у меня вызывают негативные эмоции по поводу ASA - только ее средства администрирования. Точнее мониторинга текущих соединений, блокировок, дедлоков.... Неудобно :((. Хотя мнение сугубо частное.