GeenS0) Мне лично по душе двухзвенка, да еще и на MS SQL ибо я это знаю и делал многократно, но мне также нужно понять аргументацию предлагающих апп.сервер, т.е почему они утверждают, что без него не обойтись? при том, что я безусловно резко понижу требования к числу юзеров. Как справедливо было замечено выше - лучше добавлять базы данных по мере необходимости и умощнять сервера. Но вдруг и правда MS SQL в какой-то момент не прожует поток данных? и эти хлопцы окажуться правы? у меня нет опыта на таких крупных системах и мне надо авторитетное мнение.
Еще раз повторим - поток данных, который обрабатывает сервер БД, и апп-сервер - это две разные вещи, никак между собой не связанные. Если передавать поток данных через 10 звеньев, то он от этого не станет меньше.

GeenSА ведь как-то надо получать столистовые отчеты...какие приемы здесь возможны? предположим мы все предусмотрели: и транзакции компактные, и курсорами не злоупотребляем, а по возможности вообще избегаем, но ведь отчеты есть отчеты - сколько попросил столько и будет? какую методу Вы бы применили?
Отчет придется передавать в любой системе - хоть двух хоть в пятизвенной, потому разницы нет никакой. Главное правильно сфформировать отчет, чтобы не передавалось лишних данных - это касается вообще любых архитектур, т.к. большим трафиком можно и локалку нагнуть.

GeenS pkarklin1. Можно и без него.
2. Совсем не обязательно.

Т.о получаем варианты

1) MSSQL+webservice+IIS+browser
2) MSSQL+webservice+desktop application
3) MSSQL+IIS+browser

На Ваш взгляд наилучшее соотношение по параметрам надежность/безопасность/удобство пользователя какой вариант дает?
2 вариант - я доволен его работой.
IIS конечно обязателен в этом случае.
Можно кэшировать часто используемые данные, которые редко меняются (вебсервисы) - это к тому, что если сильно захочется, то можно таки разгрузить сервер БД :)
К тому же, можно увеличить число серверов с IIS, если потребуется.

-- Tygra's --
Мои фотогалереи тут и тут

GeenS pkarklinНа стороне вебсервиса топтать, передавать, на клиенте распаковывать.

это у вебсервиса есть собственные средства упаковки/сжатия т.е. это свойство запроса к сервису? или делать файл, паковать внешними средствами и полученный файл ими же раскрывать?
Для .net наверняка есть библиотеки, которые на лету жмут информацию, например в zip.
Получаете от сервера ответ, жмете и отправляете в результат вебсервиса, клиент получает и разжимает. Для Delphi например тоже есть библиотеки для сжатия-разжатия.

-- Tygra's --
Мои фотогалереи тут и тут

iscrafm GeenSНачало укладываться что-то в голове...
в итоге пришли к апп-серверу интересно со стороны наблюдать.
Да как раз получается, что нет, не к апп-серверу, а к трехзвенке, если можно это так назвать :)

Потому как по вашим с прохожим определениям, апп-сервер должен раздавать приложения :)
А в данном случае он ничего не раздает - он только данные переправляет из БД клиенту и обратно.

Это можно считать заменой ODBC :))

-- Tygra's --
Мои фотогалереи тут и тут

iscrafm tygraЭто можно считать заменой ODBC :))

web service = ODBC :)
И то и то предоставляет доступ к СУБД => по сути одно и то же :))
Это когда в сервисах не зашита бизнес-логика.

-- Tygra's --
Мои фотогалереи тут и тут