Репликация с SQL Server 2005 Express Edition и SQL компактный выпуск 3.5
Я не знаю Oracle, что хорошо, в частности, но предыдущий опыт с сетевыми протоколами для других баз данных сказал мне, что они полностью игнорируют проблемы задержки. Другими словами, даже если нет чрезмерно большого объема данных для передачи, вещи могут все еще стать ледниковыми, если необходимо совершить несколько поездок в прямом и обратном направлениях в сервер для каждого значения.
Вы могли протестировать эту теорию, если бы Вы добавили немного задержки к своей сети (я знаю, что это возможно в Linux, я могу только предположить, что существует некоторый способ сделать это в Windows), и видящий, влияет ли это значительно на общее время выполнения.
Другая опция состоит в том, что часть обработки может делаться на стороне клиента, которая могла передавать намного больше чем 5 ГБ промежуточных данных для получения результата. Это, вероятно, обнаружилось бы как некоторый довольно известный объем нагрузки на Ваш рабочий стол, хотя, таким образом, это не все настолько, вероятно.
Да можно сделать это с SQL Express. Вы захотите использовать репликацию sql server, чтобы сделать это. Необходимо будет использовать Рабочую группу или более высокий сервер как средний сервер, который говорит со всеми другими.
Вы, вероятно, захотите репликацию транзакций или объедините репликацию. Оба - псевдореальное время.
Репликацию sql server обычно очень легко настроить, но Вы не можете опубликовать от базы данных экспресса SQL Server (см. статью ниже).
Если Ваша центральная база данных рядом (разговор сети) к терминалам, Вы могли бы просто соединиться непосредственно с центральной базой данных с помощью тонкого / толстого клиента.
Репликация слияния работает хорошо, но всегда существует что-то вроде задержки, так как слияние происходит в расписании/по требованию; это походит транзакционный, было бы лучшее пригодное для 'немедленно видимых' операций базы данных.
Однако я только рекомендовал бы репликацию, когда у Вас есть несколько офисов или определенное обоснование для использования нескольких баз данных (т.е. поддержка иногда связанных приложений). Это кажется, что единая база данных с тонким / толстым клиентом была бы более оптимальным вариантом (IMO).