GeenSНа самом деле вот что: или БЛогика на сервере БД и доступ через веб сервисы или БД+аппсервер+тонкий (веб?) клиент

Зачем же в крайности впадать.
БД (в которой реализована часть логики) + аппсервер (в котором реализована другая часть логики, расчеты, подготовка отчетных данных и т.п.) и клиент подключенный через веб сервисы (в котором тоже реализована часть логики).

Вот вы говорите веб, вот представьте получили вы списки показаний например с АСКУЭ (1 список на 10000 ТУ, а то и больше) вы их че в случае с каналом 64к на e-mail будете отправлять чтоли? А отчеты в 200-300 страниц, тоже по мылу гонять?

1024пусть что угодно выпоняет.

В случае скл сервера весь расчёт пройдёт быстрее и ресурсов потребует меньше. Практически всегда.
Вы видимо с трудом представляете объем вычислений в поставленной задаче.
Что на счет MSSQL то практикой доказано, что математические вычисления на T-SQL выполняются медленнее, чем классическими win32 средствами.

1024неправда. Чтобы сделать select sum(...
В вашем понятии вычисления это select sum() ?
Вы чтонибудь слышали, об интерполляции, экстраполляции показаний ПУ? А о получении чисто аналитических данных, таких как потери в отдельно взятом районе? Это все тоже MSSQL будет считать, при таких количествах абонентов?

1024понятия не имею кто и что будет считать. Я сказал о том что сервер приложений в подавляющем большинстве случаев подменяет стандартный функционал скл сервера. И делает это хуже чем сам скл сервер.
Никто и не говорил, что все нужно отдать серверу приложений.
А "делает это хуже", не сервер приложений, а его разработчики. :)

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

pkarklin iscrafmИ зачем зациклились на выборках? Их выполняет сервер СУБД. Возьмите например задачу забрать с FTP файл, сделать его парсинг и записать в таблицы СУБД.

Я сделаю это только с помошью функционала, предлоставляемого сервером (DTS). Не нужно мне писать для этого апп. сервер.
Хорошо, пусть так, а несколько тысяч пользователей с каналами в 64к вы предлагаете законнектить прямо к серваку?

pkarklin Прохожий..... pkarklin iscrafmИ зачем зациклились на выборках? Их выполняет сервер СУБД. Возьмите например задачу забрать с FTP файл, сделать его парсинг и записать в таблицы СУБД.

Я сделаю это только с помошью функционала, предлоставляемого сервером (DTS). Не нужно мне писать для этого апп. сервер.
Хорошо, пусть так, а несколько тысяч пользователей с каналами в 64к вы предлагаете законнектить прямо к серваку?

Не совсем понятно, что Вы хотели спросить:

1. Выдержит ли сервер несколько тысяч коннектов (а с чего бы ему не выдержать?)
2. Или, речь идет именно о ширине канала в контексте скачивания с FTP?

Если второе, то забирать с фтп будет сервер, а не пользователь, уж у сервера то в инет канал должен быть хороший (раз мы хотим чего то скачивать).
При чем тут FTP? Топик был если вы забыли, о расчетной биллинговой системе, а не об отправлялке файлов на FTP. Сервер то выдержит тысячи коннектов, но нужно ли это? Сможете ли вы на сервере легко реализовать логику способную отправлять и получать данные на таких узких каналах?

tygraИ чем таким отличается логика, которая должна работать на узких каналах, от обычной логики? :))

-- Tygra's --
Мои фотогалереи тут и тут
Чем? Объемами передаваемой информации.