REBUSПредлагаю рассмотреть такую тему.

Много разговоров на форуме:
Как проектировать систему?
Как с удаленными офисами работать?
Как обеспечить синхронность единых баз данных и справочников.
Как обеспечить "мгновенное" выполнение операций (с валютой, объектами учета)?
Как обеспечить быструю требуемую скорость отклика в программе у пользователя?

А ведь ответы на эти вопросы уже давно есть.

Нужно присмотреться к действующим системам:
1) Банкомат и пластиковая карточка;
2) Банковские информационные системы;
3) Система продаж ж/д билетов ("Экспресс");
4) Система продаж авиабилетов ("Амадеус"или "Габриэль").


Вопрос действительно интересный. Но сразу оговоримся. Во всех приведенных выше действующих системах проскакивает минимум информации. Если брать в рассмотрение любую учетную систему, то объем информации, который там "гуляет", несравнимо больший.
Я работал с системами продаж авиабилетов. Более того заставлял с ними работать свою программу.
1. Там терминальный доступ
2. Системы понимают только команды(этому еще научить нужно)
3. Вывод информации весьма специфичен и все в кодах-попробуйте запомнить коды всех аэропортов или городов.

Теперь о главном.
Для того чтобы система могла работать с удаленными офисами и обеспечивала мгновенное выполнение операций прежде всего ее нужно удачно спроектировать и "заточить" под конкретный SQLсервер.
Все остальное в корзину.
Примеры.
Перевод 1С на SQL платформу. Пошли самым легким путем. Ничего не было сделано для оптимизации скорости работы. Просто подменили драйвер и отправили в плавание. Сами 1С-программисты признают что с DBF работает быстрее. Это же нонсенс...
А эти мультиплатформенные системы с использованием серверов приложений и т.д. Фактически городят огород. Создают прослойки между пользователем и БД, которые просто по определению задерживают выполнение запросов. Как можно работать в этом случае? Только используя стандартный SQL92 без каких либо особенностей конкретного SQL сервера. МОжет конечно и можно серверную часть написать под каждый SQL сервер свою, но поддерживать такое ох непростое занятие.

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

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

P.S. Все озвученное выше исключительно ИМХО и личный опыт работы с удаленными пользователями. Никаких претензий на правду в конечной инстанции:)

Александр Гoлдун
В этом плане не вижу никакой особой специфичности этих задач. Чем удаленное рабочее место кассира где-нибудь на Камчатке отличается от аналогичного в Москве рядом с серверами?

Для Вас или для меня может и никакой разницы. А попробуйте запустить с Камчатки клиентское приложение одного из известных ныне "брендов" и Вы все увидите:)

Александр Гoлдун
Специфичность постановки пдобных задач только в том, что каналы могу иметь весьма ограниченную ширину, и то, что приемлемо на локалке в 100мбит на канале 64к может оказаться непригодным для работы.
Так если разрабатывать изначально под небольшой канал то будет счастье. А как оно на 100бит будет работать-вообще сказка.:)
Я как то давно делал систему для продажи билетов в кинотеатре, так один из конкурентов, дабы хоть как то ускорить работу своей системы бросал кабель от каждого клиентского места прямо к серверу. Я правда не помню как он это все хозяйство разрулил у сервера. Но вот такая вот была сетка.:)