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

P.S. Так же предлагаю рассмотреть вариант использования не MSSQL, а сервера Sybase ASA , на котором во первых можно реализовать достаточно более продвинутую бизнес-логику в БД (к примеру SELECT FROM SP() дает очень большие возможности), во вторых обеспечить надежную криптографию по собственным 128-разрядным ключам протоколов передачи данных и самой БД, а так же сжатия пакетов протоколов, в третьих организовать оффлайн репликации с выносом подписчика БД на удаленный узел, что позволит удаленным точкам работать в интранет, где сама ASA через почту или FTP уже будет сеансово реплицировать изменения между удаленными узлами и консолидированной БД. После MSSQL переход на ASA занимает минимум времени с учетом того, что ASA поддерживает в т.ч. TSQL, как показывает моя практика, репликации ASA с учетом достаточно обширного присутствующего функционала, позволяющего легко организовать любую схему репликации (движения информации), у специалистов MSSQL в среднем уходит неделя. Здесь возможности ASA позволят более легко организовать увод логики в БД, для C# существуют собственный нативный провайдер и DBExplorer под VS.NET, оффлайн репликации позволят не ограничивать работу в зависимости от широты каналов и наличия интернета, а иметь разумный выбор между онлайн работы напрямую через интернет с консолидированной БД и оффлайн работы с локальной БД для медленных и нестабильныхъ каналов, криптография и архитектура сервера дадут хорошую гарантию от взлома передачи данных или кражи консолидированной или удаленных БД, нетребовательность сервера к ресурсам позволит работать на имеющемся парке оборудования без его требования к обновлению, нулевое администрирование снимет необходимость наличия квалифицированных администраторов на консолидированной и удаленных БД, наличие встроенного OLAP даст возможность разрабатывать сложные аналитические запросы для отчетов, ну и кроссплатформенность позволит не привязываться монопольно к одной ОС (тут поддерживаются не только Windows, Unix и Linux платформы, но даже Netware и MacOS). Ну и последний очевидный плюс - это легкость сопровождения продукта его разработчиками у клиентов, от наличия возможности синхронизации схем удаленных БД через репликацию и к примеру заканчивая моей собственной разработкой системы синхронизации версий баз ASA, где сервера сами через веб-сервисы сеансово подключаются к хранилищу версий скриптов и автоматически синхронизируются с изменениями, проделанными в эталонной БД, сначала проведенными и подтвержденными на тестовой БД, где все изменения и контроль синхронизации управляется через веб-интерфейс, полностью написанный только на ASA. Все это мое личное мнение, но оно основано на множестве примеров удачных реализациях подобного класса задач множества специалистов, где в качестве платформы изначально планировался MSSQL или Oracle и далее происходил отказ в пользу ASA (где то сразу, где то даже с переводом существующих и работающих проектов).

OTigerКак это только в C# можно реализовать... Да и плюсы такого подхода сомнительны. На коннект уходит время, а значит время отклика системы увеличивается, не проще на одном коннекте работать, а в случае обрыва соединения уже подключаться заново.
И что же там сложного в реализации то ? А время отклика системы - юзер получает данные, работает с ними, сохраняет изменения. А значит подключения идут только на момент получения и сохранения, т.е. фактически все время соединение юзеру просто не нужно, а основное время как известно тратиться на работу, а не получение/сохранение. С точки зрения стабильности интернета и кол-ва коннектов на сервере достаточно актуально, чтобы принять во внимание.

OTigerКак будто только в ASA можно так работать с SP()...
Ну ка - и кто же у нас еще умеет полноценно использовать SP в любой сложности запросах без ограничений ? Interbase-клоны что ли ? Так они по эффективности соединения ХП с другими обьектами в запросах работают методом возврата курсором записей. В MSSQL так называемые UDF - так там столько ограничений, что мало не покажется.

OTigerНу остальное как обычно бла, бла, бла - реклама ASA. :-)
Все остальное "бла бла бла" ни у кого больше нет, поэтому всегда при выборе таких проектов стоит обращать внимание на возможности ASA.

Вот поэтому я и стараюсь заниматься тиражными продуктами - здесь как раз СУБД идет со своими лицензиями в комплекте поставки продукта, требуются высокая защита информации, оффлайн репликации и отсутствие сопровождения - здесь самое оно для ASA, клиенты особо про нее и не задумываются - просто работают продукты и работают сами по себе, все централизованное сопровождение фирма разработчик прямо через тот же интернет автоматом спускает на БД и клиентские приложения заказчика и спокойно интегрируется через прокси механизм удаленных серверов, веб-сервисов и XML с другими, "явными" серверами, которых в избытке у клиентов, что MSSQL, что Oracle ... Так что если есть возможность выбора платформы, то просто странно зацикливаться на MSSQL, когда рядышком есть более удобная и недорогая ASA, которую можно смело позиционировать как интегрирующийся в продукт сервер и не забивать клиентам мозги лицензированием, сопровождением, администрированием и т.д.

авторЕсли же я заикнусь о SyBase-на меня посмотрят странно:) В этом кстати вина и самого представительства SyBase. Народ хочет работать с самыми распространенными продуктами. Но это мы что то уже выбились из темы:)
Честно говоря "поубывал бы" кой кого из Sybase ... Не я один и не обязательно в России ... например у нас недавно муссировалась забавная на форуме iAnywhere самих разработчиков ASA тематика - как бы переименовать Sybase Central (консоль управления сервером) в ASA Central или Watcom Central, чтобы людей не отпугивало слово "Sybase", которое у них сразу с ASE ассоциируется ... Так что нам тоже приходится много раз доказывать, что мы не Sybase, а iAnywhere (бывший Watcom) предлагаем в качестве платформы, здесь есть определенной доли идиотизм, что нам приходится не только это делать, но еще и боротся с самим Sybase, который упорно пытается всех клиентов уговорить перейти на ASE (ситуация по моим сведениям распостранена по всем Sybase представительствам мира). Здесь конечно продукты на базе MS или Oracle имеют действительное преимущество - их не приходится самим рекламировать, так как они достаточно популяризированны самими представительствами.