>>Если ни то, ни другое, то, может быть, имеет смысл уточнить, что именно имелось в виду.

сорри за нечеткий вопрос

имеется ввиду линейная (ну почти линейное :) ) масштабируемость системы за счет изменения мат. базы, без изменения ПО. Т.е., садим еще пару сотен пользователей. Хотим сохранить существующий уровень производительности (например, стабильное время отклика).
В R/3 это можно сделать изменяя конфигурацию сервера БД. Но этот путь имеет свои ограничения.
А можно увеличить число app servers, причем вопросами балансировки нагрузки на app займется сама система (специльный сервис R/3).

Если архитектура двузвенная (физически) то возможен только вариант 1. На данный момент кластер для sql server можно использовать только для обеспечения отказоустойчивости (в отличие от oracle).
В Юконе можно увеличить производительность системы покупкой дополнительного сервера без изменения ПО (или с минимальными изменениями настроечного характера)?

1 понятно, что реализовывать бизнес-логику на sp для промышленный ERP - геморой. Я вижу два препятствия здесь:
- завязка на конкретную СУБД;
- производительность, вернее, проблемы с масштабируемостью
2 R/3 использует sp в случае, если СУБД ms sql server. Это не десяток технических sp. У меня в системе их число доходило до 500 000 (что тоже геморой :) ). Как я уже говорил, app server не шлет поток sql операторов, а на каждую инструкцию open sql ("мультисистемный" диалект sql от sap ) создает sp. Название sp привязано, как бы это сказать, к текущей версии исполняемого на app server программного модуля.
3 про блокировки. Наверно надо открыть новую тему - использовать ли в ERP системе блокировки СУБД? Для затравки, r/3 имеет собственный механизм программных блокировок на бизнес-объекты (точнее, объекты репозитария)

Quark
Идем далее: видим что есть TSQl, PSQL,ISQL ... Пытаемся абстрагироваться от конкретной СУБД и делаем все на СКЛ92.

Минус номер два: изобретаем велосипед. Но зато получаем некую универсальность. И вот тут закрадыватся возможность ОЧЕНЬ большого минуса. Разработчик может быть не любителем СКЛ и начинает реализовывать не обход аддишинов реализаций СКЛ, а сами аддишины на ООП.
Вероятность что получим большие тормоза очень большая.

(С)ИМХО)

минус номер 2 происходит от некачественной постановки проведения разработок в системе - без контроля качества, верификации ТЗ и проч.

Quark
Далее получаем много версий уже внутри бизнес логики. И теперь наступает звездный час.
Ничего не напоминает?
(С)ИМХО)
откуда много версий внутри бизнес-логики? не понимаю

Quark
Пытаемся единообразно подойти к методологии получения данных для OLTP и Report данных на клиенте. Делаем много много маленьких запросов и забрасываем ими сервер.
(С)ИМХО)

кто говорит, что в ERP системе есть единообразные методологии получения данных для oltp и report? Нет такого. Есть системы отчетов, заточенные на определенные модули (FI, SD, контроллинг), есть возможность написания собственных отчетов на внутреннем языке erp, есть, в конце концов, возможность для report создать хранилище данных \ olap.