Arm79Вопрос то в чем? Мы же не знаем, что нужно человеку. Для задач вполне может быть использована двузвенная архитектура. Третий слой (логику) можно эмулировать вызовом хранимых процедур.
...

По-моему, вы просто путаете термины, вот вас и не понимают тут.

"Трехзвенка" == "Three-tier"
"Третий слой" == "Third Layer"

https://stackoverflow.com/questions/120438/whats-the-difference-between-layers-and-tiers

Так что третье звено никак не эмулировать хранимыми процедурами, как бы ни хотелось поизвращаться

Arm79betelgeizex,

Я ничего не путаю. SQL-сервер вполне может быть сервером приложений. Сервер приложений - это дополнительная логика, бизнесовая, которая не относится к DML.

В данном случае просто 2 звена физически расположены на 1 машине (хотя есть варианты с Linked Servers).

Другое дело, что это не всегда удобно. Но факта это не отменяет никак.

Ну нет же.
.NET-приложение, например, может содержать в себе много слоев (layers). Слой доступа к данным, слой бизнес-логики, слой представления...
Но это не отменяет факта, что все три слоя находятся в одном физическом звене (tier).

Точно так же и SQL-сервер: в нем есть "слои": tables, views, procedures.
( Вон, к SQL 2005 можно было вообще по SOAP запросы отправлять. Потом, к счастью, это объявили deprecated )
Но это тоже одно звено.

Как критерий: звенья могут масштабироваться независимо. Один SQL-сервер, к нему цепляется кластер из 10 IIS-приложений. Возможно и наоборот...

А могут процедуры в БД масштабироваться отдельно от таблиц? Нет!

С Linked Servers, кстати, можно сделать трехзвенку - когда БД с процедурами обращается по сети к БД с таблицами.
Но это уж совсем наркомания какая-то ;)

Arm79,

БД не может быть сервером приложений по определению ) Я же толкую исключительно про термины.

Давайте скажем так: SQL-сервер вполне подходит для размещения на нем слоя бизнес-логики . Тут я полностью согласен.

А вообще, безотносительно задачи, у логики в БД масса минусов.

Язык ХП беднее языков общего назначения. И синтаксис кошмарный, ИМХО :)

Логика в БД плохо масштабируется - писал уже

Extended procedures на Java/C#/C++ etc. могут негативно влиять на стабильность и производительность БД. А раз могут, то будут ))

Большой шанс, что в дальнейшем потребуется веб-клиент, даже если руководство клянется, что не понадобится

Сильно сокращаются варианты интеграции с внешними системами

Существенно сложнее версионировать API (поддерживать несколько версий одновременно для разных клиентов)

Вижу только три варианта, когда есть плюсы:


Есть специалисты по БД, но нет по .NET

Уже понаписана куча легаси на ХП

Логика заключается в перекладывании больших объемов данных из одних таблиц в другие