Приветствую.

Собственно данный сабж подымаю я по той причине, что не могу найти решение своей проблемы.
А суть ее состоит в следующем.

Есть на нашем предприятии не маленькая база на оракле (> 100 Гб).
Доступ к ней имеют куча народу, и каждый что-нибудь новое в нее запихивает.

Очень много логики лежит на сервере в PL/SQL-ных пакетах.
Интерфейс пользователя реализован на дельфях и все сводится, как правило, к тому, чтобы показать набор данных, чтоб потом на основе представленной в нем информации пользователь мог вызывать нужную ему процедуру из базы, передав туда требуемые данные.

Архитектура классическая - клиент-сервер.

До какого-то времени этого всего хватало.

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

Поддерживать все это хозяйство тоже становится трудно, неговоря о том, что приходится мириться еще и с кучей других минусов.

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

Попытался найти какой-нибудь полуфабрикат-фреймворк, но ничего дельного не нашел, наткнулся только на компоненты RemObjects Data Abstract, представляющие собой якобы довольно популярную альтернативу DataSnap, сейчас пробую разобраться, но у них документация накидана в кучу, нечерта пока что не разобрать.


Мне то собственно вот чего бы хотелось от новой архитектуры:
1. Тонкий клиент. Т.е. чтоб если и была какая-нибудь логика, то она бы лежала на сервере приложений, а у клиента был бы просто терминал, для ввода и вывода данных.
2. Обратная связь с клиентом. Т.е. чтобы сервер приложений мог управлять подключенными к нему клиентами, например, обновить данные в гриде.
3. Интерфейс к базе должен быть только через сервер приложений. Т.е. чтоб никто из пользователей не мог подключиться к базе и отправить ей произвольный запрос (прямого подключения не будет даже физически), а работал бы только через сервер приложений, отправляя ему те команды, которые он в может обработать в соответствии с правами пользователя.
4. Разгрузка сервера БД. Сейчас он уже начинает кряхтеть, а с сервером приложений можно было бы гибче управлять очередями пользователей, можно было бы избавиться от большого количества блокировок в базе.
+ удобство сопровождения - достаточно поменять какую-ту логику на сервере один раз, чем в нескольких отдельных клиентах (ну это следует из п.1.)


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

Но пока что есть только RemObjects и то, документированный как попало.

Может кто-нибудь из вас сталкивался подобной проблемой, может поделиться опытом и посоветует что-нибудь полезное?     

Заранее благодарен.

Например

Добавлено через 3 минуты и 38 секунд

База данных ведь своя, самописная? Я не представляю даже, что это могут быть за такое УНИВЕРСАЛЬНЫЕ программы для обычных пользователей для работы  с базами.

ИМХО сомневаюсь я что трехзвенка облегчит тебе жизнь, скорее наоборот....