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

Почему сервер приложений должен заниматься такими вещами, как изоляция, блокировки, сортировка, джойны, фильтры итп ?

DrKonitoИз-за нестандартности интерфейса самопального сервера придется самому писать тонны кода, вместо использования стандартных решений.

Это самый главный аргумент против СП. Но почему все ведущие производители ERP-систем используют n-звенную архитектуру и никто не держит бизнес-логику в хп? У меня есть пример одного предприятия, в котором из-за обилия и сложности хп на пределе работал 4-хпроцессорный сервер. Только не говорите, что у них кривая структура БД.

ВМоисеевНадо учитывать высокую вероятность нежелательного перехвата конфиденциальной информации посторонними лицами. Вы обязаны криптографически защищать трафик.

А не проще ли шифровать трафик на шлюзах в интернет?

tygraА кто сказал, что сервер данных предназначен только для этого? Этак можно и в dbf данные держать - то же самое получится.
Если Вы не понимаете, в чём разница между обработкой 10^n строк в СУБД и dbf - дальнейшее обсуждение не имеет смысла.

ВМоисеевDrKonito
>Теперь эти люди в перерывах между объяснениями почему мы слезли с пальмы и как у нас все плохо, предлагают для начала написать побольше бизнес-логики на шарпе, запихнуть её "для начала" в толстого клиента, а потом уже разбираться с архитектурой :)

Примерно что-то аналогичное сделал. Работает. Бизнес-логика на шарпе. Толстый клиент. По сетям гоняю только данные. Свой подход описал в цетируемой статье. Не подскажешь как связаться с твоими аппанентами?

Работать-то работает, пока эта задача не выйдет за пределы локальной сети.

!!! Простой рабочийОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.И что этот пример показывает, кроме низкого качества проектирования и реализации?

tygra Простой рабочийОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.Это говорит о том, что вы не умеете работать с sql, с ХП и т.д.

Я привёл пример размера кода не самого большого документа, а всего лишь алгоритма формирования бухгалтерских проводок накладной. Меня поразили Ваши ответы. У нас с Вами слишком больша разница в понятии бизнес-логики. Возможно я ошибаюсь, но вы не рабтали с ERP-системами (или хотя бы приближенными к ним).

ASCRUS Простой рабочийнашёл в книжном магазине пару интересных книжек по пострению 3-хуровневых систем, которые меня ещё сильнее убедили в такой необходимости.Было бы конечно странно, если бы они разубедили. Может быть теперь купить и почитать пару книжек, наоборот описывающих плюсы и ньюансы двухзвенных приложений и критикующих 3-х звенки ?

Может. Жду примеры книг, с удовольствием прочту.

ASCRUSвсе решалось стандартными средствами, где в БД помимо самих данных на себе описывала и хранила модель и процессы бизнес-логики, а клиентские приложения только вызывали нужные ХП и занимались своими основными задачами - построением для пользователя удобного и адекватного интерфейса.
Я бы и не задумывался над СП, если бы система была бы не сложной.

DrKonitoСравнивая Контору1 и Контору2 отмечаю следующие факты:
1) 3х звенка тормозила на 30 пользователях, в Конторе2 нормально работают 200 пользователей, несмотря на то что половина мест на жутко неэффективном ацессе.

Спасибо за замечания, очень полезные! По-порядку.
Контора1 делала случайно не 1Сv77 SQL? Эта на такое способна :-)

DrKonito2) Класс разработчиков в Конторе1 был серьезно выше. Им приходилось заниматься действительно нетривиальными проблемами. Но не сказал бы что это является преимуществом 3х звенки :)
Абсолютно согласен. Хочу найти технологию по-проще :-)

DrKonito3) Любого человека который приходил в Контору1 надо было учить фактически с нуля. Первые полгода-год от новых людей было очень мало толку. В Контору2 можно взять студента на 400 баксов с базовым знанием SQL и быстро поставить его в строй.
Не согласен. Когда система грамонтно организована на классовом уровне - как раз в этом случае студенту с улицы легче разобраться, чем копаться в жутком трёхэтажном коде запросов на T-SQL со множествами JOIN и подзапросами.

DrKonitoКстати в несколько другой области лучшим примером толстого клиента является пресловутая 1С-ка. Она тоже по сети гоняет только данные :)
Это её недостаток, но писать в ней код - одно удовольствие. Может это и кошмар для сисадминов, но для программеров - шоколад :-)

Дмитрий Сорокин Обратный пример - самописная учетная система - типичная 2-х звенка, вся логика в хранимых процедурах, MSSQL, 600 одновременных пользователей, 300Gb база, 300млн. проводок, перелезли с 8хXEON700+8Gb RAM на 8xITANIUM2+8Gb RAM , потому что стало подтормаживать - теперь снова летает. Но, конечно, система вылизывалась достаточно долго.
Сервер масштабируется до 24 процессоров и 32Gb RAM, поэтому лет на 10-20 хватит.
При этом года 3-4 назад vs активно игрались с MTS и DCOM. Переписали основную бизнес-логику по проведению проводок на С++, оформили как DCOM объект под MTS, запустили на тестирование. Может, конечно, у нас руки росли не оттуда, но там, где справлялся 1 MSSQL-сервер нужно было ставить десяток MTS-серверов, чтобы добиться той же производительности при 300 одновременных коннектов.
Круто! DCOM, значит отпадает...
Что такое MTS?