Не подскажу как по учению и экзаменам, но в жизни опыт диктует следующее:

Оптимальным решением (любой сетевой) задачи являеться 3-х уровневая клиент-серверная система. Сразу оговорюсь - КОНКРЕТНАЯ задача накладывает СВОИ корректировки в поиске решений. На клиенте как правило расположен графический слой (интерфейс с пользователем), бизнес слой (это отображение в коде Вашей, конкретной предметной области). На стороне сервера - апликэйшен сервер (в принцепе по структуре он повторяет слой бизнес логики, но как правило не содержит экземпляры обьектов бизнес логики), и службы (базы данных, порты, сервера печати, крылышки у сервера, хрен знает ещё что).

Риски (как правило) встречаються на этапе создании группы единомышленников, декомпозиции предметной области - нахождение сущностей (в зависимости от Вашей задачи), организации процесса как ПРОИЗВОДСТВА.

это коротко
с уважением
(круглый)

BusyManОни уже летать научились?

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

Например, если БД по своим возможностям перекрывает потребности - то вполне вероятно, что городить сервер приложения не имеет большого смысла (особенно если задача конечна, функционал ясен и всё ложиться в рамки например СУБД Oracle). Хотя по мне - таких задач практически нет. Или по другому... При "закладке" сервака приложения - создаваемый код (как не странно) значительно сокращаеться. И есть возможность всегда "сыграть" переносом "тяжести" реализации на клиента либо на сервер (по разному бывает - молиться на стандарты не стоит).


с уважением
(круглый)

tygra
Где же вы были в том легендарном топике про многозвенки???!!!
Раз уж он почил, может здесь представите примеры тех задач, которые нужно решать через многозвенку?
Особенно учитывая, что по поводу При "закладке" сервака приложения - создаваемый код (как не странно) значительно сокращаеться были совершенно противоположные мнения, которые были всеми же и подтверждены.
-- Tygra's --

"...в топике..." ну во первых не видел, на Вашем серваке - недавно. А во вторых, а смысл ? Типа наших бьют ? Ведь всё равно у каждого свои взгляды на тот или иной аспект.
"...многозвенки..." кхм...звучит заманчиво... В плане сокращения труда и народного гимора. Посему ставлю как неясный термин. Если хотите - уточняйте. На мой взгляд очень занятное слово приминимо к сетевым технолгиям.
"...задач..." на мой взгляд любых. Критерий обратного - простота и одноразовость проекта. Т.е. чем он примитивней и разовый - тем меньше нужно лезть в данную область.

в качестве ответа. кхм. ну пускай будет клиринговый центр. Это нечто, охватывающее авторизацию дисконтной, депозитной и внешней процессинговой авторизации. Сфера - обычный супермаркет. Виды карточек... А пускай будет универсально.. Visa, DClub, AmEx, UC, UCS и другие (если клиент хочет работать с другими). Плюс возможность заводить свои дисконтные и дипозитные. Приурочим это всё к компьютерным POS, работающих под досом. Сеть - Novell (пускай будет 3 или 4). Добавим сюда: закачку стоп листов (сжаты), пересылка отчётов по транзакциям за опер. день. Различные сценарии дозвона и каналы авторизации.

можно что нить попросче.
Ну например поиск контекста в неизвестных файлах на нескольких серваках под разными OS.

почему кода меньше. кхм. как Вам сказать, в своё время я и сам удивился не мало. Скажу по другому - я использовал это как лакмусовую бумажку при проектировании систем. Если код дюже усложняеться - пора проверить консерваторию.

и ышо. К сожалению, литературы по этой тематики - МАЛО. Имею ввиду не юзанья готового решения (к сожалению технология не передаёться по наследству) а именно РАЗРАБОТКА, методология и распределение узлов. И от программиста требуеться немного переосмыслить стандартное "плоскостное" программирование при использовании данных технологий. На мой взгляд - "впереди планеты всей" лучше ориентируються (что ли) это Юниксоиды. Это по опыту общений на всевозможных выставках. Когда модное пошло словосочитание клиент-сервер. Ну как тут не "натянуть" свою плоскостню на данное понятие - только ленивый этого не делал :)


с уважением
(круглый)
ЗЫ
Без обид..

Изначально - вопрос был ближе к академическому (как мне кажеться). Выше я привёл ОБЩЕЕ понимание клиент-серверной архитектуры. В данном сообщении было:
а) указание на то, что архитектура программы сильно зависит от КОНКРЕТНОЙ ЗАДАЧИ.
б) использование БД есть ЧАСТНЫЙ СЛУЧАЙ данной технологии.
в) по наследству клиент-серверная технология НЕ ПЕРЕДАЁТЬСЯ.
г) Рассуждения о звеньях - есть чиссо НАДУВАТЕЛЬСКИЙ термин из эпохи ВПАРИВАНИЯ СОФТА.
д) ... могу очень много написать :) Смысла не вижу, т.к. переубедить кого то - вряд ли мне удасться (да и зачем ?) - посему заткнусь.


по поводу задач. Увы и ах - только такие в жизни и встречаю. То, что было мной сказано о возможностях БД перекрывать функционал - НЕ есть противоречие выше сказанному. А больше выражает взгляд ВЗЕШЕННОГО ПОДХОДА при реализации различных (опять повторюсь) КОНКРЕТНЫХ задач.

Клиент-сервер это термин относиться (увы) только к софту в котором РЕАЛИЗОВАН и КЛИЕНТ и СЕРВЕР. никак иначе. В попытки убить флейм, предлогаю ЛЮБОЙ процесс явно (или НЕ явно) юзающий сеть звать КЛИЕНТ-СЕРВЕР (ведь всё равно на уровне сетевых драйверов это ТИПИЧНЫЙ клиент-сервер) :) а это - питер нортон, дос, милкософтовский офис и т.д. и т.п..(к этой абсурдности Вы не придёте если согласитесь с пунктов "в" нарисованным выше. Правда он же заставит пересмотреть многие Ваши знания :) ) Вы только ради бога не обижайтесь... Очень многие так смотрят на эти весчи.



с уважением
(круглый)
ЗЫ
Кстати о терминах...
В клиент-серверной технологии есть...
а) сервер - ПРЕДОСТАВЛЯЮЩИЙ УСЛУГИ.
б) клиент - юзающий рпедоставляемые сервером услуги.
и всё. это вообще то определение :) Если Вы говорите о РЕАЛИЗОВАННОЙ ТЕХНОЛОГИИ в том или ином софте - то будьте добры указать, где и что у Вас задумано и реализовано (в свете определения ессесвенно). Ежели у Вас только клиент, а сервер от папы карло (и не важно какой сервис он покрывает) - то это уже НЕ клиент-сервеная технология. аминь. :)