Имхо задача четко распадается на две:

1. Сделать решение (второй модуль) для нескольких серверов.
2. Организовать обмен данными с первым модулем.

Первое - целиком во флейм про универсальные решения для всех СУБД vs персональная реализация для каждой. Второе - согласен с советом прежде всего посмотреть готовые решения и понять, чем они Вам [не] подходят. В целом вторая часть - абсолютно техническая; даже если делать самостоятельно, будет нетрудно специфицировать универсальный интерфейс обмена и выдерживать его, таская данные универсальной программой для любых БД.

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

- Если приложение несложное, если предполагается максимальное расширение вплоть до работы с базой из dbf-файлов, то стоит смотреть в сторону трехзвенки либо универсального клиента.

- При усложнении приложения и повышении требований к эффективности нужно смотреть в сторону раздельной реализации для разных СУБД (возможно в КС, возможно в трехзвенке).

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

И обязательно прочитайте то, что говорилось "против" универсальных решений. Даже если выберете этот путь - нужно понимать, с чем придется столкнуться, какие проблемы решать.

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

double_axeКстати, а промежуточное звено - некий Application Server, как я понял?
Пока что совершенно не видна необходимость в промежуточном звене. Если задача не из легких, больше оснований дрейфовать к раздельной реализации.