OTiger
Или резервирование товара это не ввод данных?

имхо, ввод данных к резервированию не имеет никакого прямого отношения. Вернее, резервирование - процедура, которая является одним из логических продолжений операции ввода данных. На основании введенных данных можно выполнить резервирование или отгрузку. Гадать для чего оператор набрал список из 200 позиций занятие неблагодарное. Например, делал работу на завтра... Пил кофе, общался в момент набора по телефону, нажал кнопку сохранить и пошел в туалет... все люди, все человеки. Актуальность тоже понятие относительное. Разрабатываются аналитические процедуры, чтобы исключать ситуации, когда в момент отгрузки вдруг не хватит 1 коробки товара. Например, планируются переброски между складами в зависимости от кучи условий: существующие заказы, среднесуточное выбытие etc... А если на склад приехали два покупателя с одновременным желанием купить по 50 коробок товара и в наличии их всего 50, то никакая процедура резервирования не поможет, нужно искать компромисс, причем не в ИС.

Все таки немного по теме, по порядку. Какова же роль сервера приложений.

1. Управление контентом

Задача управления контентом заключается в предоставлении пользователю разрешенных ему приложений.
Структура хранения контента информационной системы может быть самой различной. Контент включет в себя описание пользовательских меню, описание интерфейсов для запуска приложений,логических связей между приложениями, формы отчетности и т.п. Любые изменения контента выполняются только на сервере приложений и сразу же становятся доступны его пользователям.

Альтернативы:

1. Хранение контента в СУБД и преобразование его в структуру содержания информационной системы на рабочей станции.
2. Реализация контента полностью на рабочей станции, т.е. перечень задач, которые решает информационная система запрограммирован в клиентском приложении.

Очевидно, что для больших и развивающихся информационных систем необходимо выбирать между вариантом хранения контента на Сервере приложений или альтернативой хранения контента в СУБД и его преобразованием на клиенте. Реализация контента полностью на рабочей станция оптимальна только для информационных систем со строго обозначенным функционалом. Любое изменение функционала требует обновления всех рабочих станций. Также следует учитывать, что постоянное построения контента на основании описания его элементов, сохраненных в СУБД (альтернатива №1) влечет за собой необходимость дополнительных вычислений на рабочей станции при каждом соединении с базой данных (построение меню информационной системы, определение доступных акций и т.п.).

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

2. Сервисы доступа к данным

Зачастую на предприятиях используется множество источников данных. данные хранятся в СУБД, причем архитектура этих СУБД часто различна. Сервер приложений выступает в качестве связующего звена между клиентом и различными источниками данных. Например, на предприятии используется система для бухгалтерского учета, которая хранит свои данные в файлах dbf формата. Для планирования производства используется система, в качестве СУБД для которой используется MS SQL или ORACLE. Множество пользователей работают с различными документами, которые храняться в виде соответствующих файлов. Сервер приложений обеспечивает доступ к этим источникам данных или документам. При этом добавление новых источников данных требует внесения изменений только в Сервер приложений. Клиент, работая только с сервером приложений, ничего не знает и не обязан знать о том, где физически размещены данные. Его задача - предоставление данных, полученных от сервера приложений пользователю для анализа и принятия решений.

Альтернативы:
1. Использование для интеграции данных встроенных механизмов СУБД. Такой вариант возможен в реализации, но детали подобной реализации сильно зависят от типа используемой СУБД. К тому же трудоемкость поддержки гетерогенных систем, где подобные механизмы решены при помощи встроенных средств СУБД значительно выше. Не все, что может сделать СП, может сделать СУБД, через интерфейсы которой выполняется интеграция. Тривиальный пример. После удаления записей из dbf файлов необходимо выполнить упаковку. Попробуйте в MS SQL сказать "pack main.dbf".


Резюме:
Если информационная система использует единственный источник данных, то нет необходимости в Сервере приложений, который будет управлять доступом к различным источникам, используя для этого средства, предоставляемые самими источниками данных. Однако в гетерогенных системах Сервер приложений дает значительные преимущества как в гибкости, так и в масштабировании.

3. Замечания по сетевому трафику.

Наверное важно знать, какой трафик между сервером приложений и СУБД. В интернете есть много обсуждений с вопросами как его измерить. Но все таки основной отрезок, на котором возникает потребность в сокращении трафика - это отрезок между сервером и клиентом, особенно удаленным. И здесь есть серьезные резервы для сокращения этого трафика. Выше приводились реальные замеры размеров recordset-а получаемого на выходе СУБД и возможных вариантов его преобразования для передачи клиенту.

Альтернатива: использовать терминалы. Сдедует учитывать, что терминал тоже "кушает", даже когда вы ничего не делаете (в отличие от клиентского набора данных), а во-вторых, работать с клиентским набором данных гораздо комфортней чем с картинкой терминала.
Резюме:
Если клиенты информационной системы размещаются в локальной сети, то не принимайте во внимание данную возможность СП, лишнее.

4. Различные сервисы
СП имеет возможность подключения различных сервисов общего назначения.
Альтернатива: реализовать все необходимые сервисы средствами СУБД.
Я бы даже не расматривал бы подобную альтернативу. Вендоры СУБД конечно предлагают различные варианты подобных решений, практически совмещая функции СП и СУБД. Все это преподносится по девизом: все в одном флаконе, значит быстрей и удобней. Привязка к одному вендору для решения всех задача не очень хорошая перспектива. Best-of-breed - очень разумное решение во многих случаях.

5. Распределение нагрузки
Хорошая задача для СУБД - управлять террабайтами, а не синхронизацией транзакций от большого числа пользователей. Все это хорошо до определенного предела и тесты производительности различных вендоров для двух и трех-звенных вариантов их приложений подтверждают это. Объединение двух, крайне несовместимых задач в одном флаконе, имхо, не лучшее решение. Конечно для десятков пользователей принимать данный аргумент во внимание нет смысла.

6. Бизнес-логика
Логика - это в большей степени порядок вычислений, чем сами вычисления. Конечно, если вычисления выполнит быстрее сервер СУБД это нужно стараться сделать на уровне СУБД. В этом вопросе часто путается понятие слоя и понятие уровня. Впрочем логика, по которой все вычисления переносятся на СП тема отдельного обсуждения.

там не сидит все на одной машине. Есть сервер БД и сервера приложений на разных машинах. Это в общем-то в правилах публикации тестов оговорено. Подробные результаты теста лучше смотреть на страницах sap/benchmark

если уж быть совсем корректным, то тесты показывают какой производительности можно достичь, используя то или иное программно-аппаратное решение. Они не сравнивают программные решения на одной аппаратной платформе. Что же касается ATO, то он более показательный, т.к. использует большее число модулей SAP и более сложные транзакции.

2 systemR
--
Как с тобой тяжело, чес. слово. Еще раз повторюсь. Тест показывает какой производительности можно достичь. Если тебе не нужно обрабатывать в час 140000 производственных заказов, то строй двухуровневую конфигурацию. А если нужно, то выстраивай систему на серверах приложений. Это показательный пример на тему масштабируемости. Сколько для этого понадобиться СП там указано. Дорого это или нет? Вопрос относительный. Если возможность обработки требуемого объема заказов принесет тебе прибыль в 1 условный млн, при затратах на сервера 200 тыс, а при объемах производства 34000 заказов в час получаешь 400 тыс прибыли - это и только это является критерием. Важно то, что используя 2-tier ты не сможешь получить такую производительность и останешься с 400 тыс прибыли вместо 800. Надеюсь доходчиво. Я же вроде и не устраиваю религиозные войны между архитектурами. Не нужно - не используй.

я ничего не доказываю, даю информацию чтобы не искажались факты :)
Естественно у нас нет клиентов, для которых Superdome с ораклом за 6 лимонов + 72 СП по 400 тыс необходимое решение, таких клиентов единицы и все пристроены. Причину нетерпимости некоторых собеседников в этом топике мне понять тяжело. Как будто кто-то кого-то агитирует. Простая тема вроде: что делает сервер приложений.

tygraЗЫ Все еще достоинствами СП преподносятся незнания возможностей СУБД и неправильная архитектура систем.
Естественно. Ни один кто использует СП не знает СУБД Да успокойтесь уже.

tygraДелается отдельный мааааленький такой клиент, специальный такой, который генерит отчеты и их отправляет. И все. Из-за этого всю систему городить через одно место?

Сказано, так сказано Вернее показано, то самое место. Кстати. Архитектура системы где клиент работает с клиентом как называется? К/К? Или Вы упорно даже в этом случае не хотите вымолвить слово СЕРВЕР, так оно Вас раздражает?

tygra
С экзотикой проблем нет - никто не против СП в таких случаях. Правда почти ни у кого таких случаев нет.

Гетерогенные системы сегодня далеко не экзотика. Скорее экзотикой является одна система на предприятии.