ВМоисеев
Меня весьма серьезно интересует вопрос, как разные SQL сервера держат нагрузку при построении страниц из отсортированных выборок из всей таблицы (число записей большое(очень), число одновременных запросов также).
Cейчас склоняюсь к мысли передавать поля (ключ, сортировочное) на сервер приложения и строить страницу там. Посмотрю скорость.
Это чистый оффтоп- тема описывается в FAQ в форуме по MS SQL.

ВМоисеевDrKonito.
Но хотелось получить и по другим, в первую очередь по Oracle, популярным серверам данных. Офтоп 100%. Для этого есть форумы по соответствующим СУБД.

Инженер
DrKonitoИмхо чтобы необходимость технологии представляющей новый уровень абстракции над "процедурным SQL" ... она действительно должна означать повышение производительности труда
Наверное, причина не обязательно д.б. в повышении производительности. Я тут подумал, использование обертки, действительно, может снизить требования к квалификации кодеров. По нынешним временам это важно.
А вы пробовали это делать? Я имел возможность сначала наблюдать, а потом заниматься этим на практике :)

Вы 400х долларового кодера видели? Обычно это человек год-другой поработавший на штуке типа Ацесса, ПХП или Икселевского ВБА.
Бэкграунд совершенно непредсказуем. Например человек может совершенно не знать, что такое реестр. Обычно бывает базовое понятие о синтаксисе SQL, если этого нет - то номер совсем дохлый. Понимание ООП обычно присутствует на уровне рассказывания на собеседовании вызубренных накануне определений наследования, полиморфизма и инкапсуляции.
Большой минус- очень трудно выбирать- потому, что все что человек знает вобщем-то не имеет значения :) Ему придется учиться заново.

Перед вами стоит задача, получить от такого персножа какую-нибудь пользу для проекта.
Как думаете, вы сможете быстро объяснить такому человеку ФирменнуюОченьПростуюОбъектнуюМодель?
Или дать ему ПодробныйУчебникПоФирменнойОбъектнойМодели, прочитав который он вольется в работу?
Не надейтесь- ВСЕГДА требуется выделенный тренер и несколько недель обучения. Даже если работа организована по принципу "кто выплывет", кто-то все-равно должен будет отвечать на вопросы.
Если думаете, что после этого вы получили полноценного кодера для проекта, то ошибаетесь. У таких людей отсутвует самое главное- ПониманиеТогоКакСистемаРаботает.
При малейшем отклонении от того, что было в учебных примерах работа встает и наступает либо ДолгийТормоз либо ДоставаниеВсехВстречныхТупымиВопросами.
Реально есть у вас выделенный тренер или нет, кто-то подобрее будет большую часть рабочего дня поддерживать ДешевыхКодеров.
Первые сдвиги появляются через пол-года\год в зависимости от умственных способностей подопытных.
Только тогда человек становится пригоден к реально самостоятельной работе. Это не значит, что они начали ПониматьКакВсеЭтоРаботает. Просто они набрали достаточно опыта, чтобы выход от них стал больше входа :) Соответственно, при любой нетривиальной проблеме они будут отвлекать тех кто реально делает работу.
Хорошая новость: через год-полтора-два понимание понимание начнет появляться. Вопрос в том, готовы ли вы ждать столько времени?

Так вот я утверждаю, что у вышеописанного специалиста в случае тупой двухзвенки первая веха- "выход больше входа" наступает через несколько недель.
Про сроки второй вехи "понимание как это работает" судить значительно труднее, потому, что она по большому счету, уже не столь значима.
Просто со временем растет понимание где какие данные хранятся и как используются (достаточно единообразным, сто раз разжеванным в литературе и поддержанным средой разработки способом) - это вобщем-то эволюционный, постепенный процесс.
Квалификация как при найме, так и при дальнейшей работе, измеряема стандартными тестами поставщиков по технологиям клиента и SQL (например MCP или брэйндампы для подготовки к нему).

Вобщем, это для меня "снижение квалификации кодеров" в случае объектных оберток бизнес-логики- типичный миф.
Я это видел своими глазами- не рекомендую. Решайте сами.

VladiCh ИнженерГы. Последние пять-шесть-семь страниц препирательств - все впустую
Ну почему впустую? Тут в основном тема объектного слоя обсуждалась, а не СП, несмотря на название топика :). И она, как я понял, еще не закончена :).
Тема объектного слоя рано или поздно приводит либо к логике в клиенте, либо к выделенному СП. Первый вариант, я думаю, малоинтересен :)
Так что говоря об "объектном слое" реально приходится говорить о сервере приложений.

VladiCh DrKonitoДля меня очевидны проблемы с производительностью, интеграцией, эксплуатацией, незрелостью используемых технологий.
Ну-ка поподробнее... Конкретно интересуют проблемы с интеграцией, эксплуатацией и незрелостью технологий. С производительностью - спорный вопрос, хотя с некоторыми оговорками готов согласиться...
В принципе я уже предлагал ответить на ряд вопросов на эту тему - я думаю моя позиция стала бы понятнее

Ок, мне не жалко переформулирую:
1)Интеграция
С интеграцией у СП плохо не в том случае, когда СП скрывает от клиента подлинный источник данных - здесь у СП все хорошо. Плохо у них, когда стороннему приложению надо взаимодействовать с вашим СП. Расскажите, как в вашей системе решаются вопросы
1.1) построения отчетов
1.2) распределенных транзакций
1.3) пакетных заданий
Я не говорю, что ни один из этих вопросов не решаем. Каждый из них решаем в том или ином виде. Вопрос в том, что ради этого вам придется писать кучу нетривиального кода, ради того, что в СУБД уже есть и этим надо просто пользоваться.
На моей прошлой работе ребята полгода собственный шедулер отлаживали (непростая тема оказывается), стандартные не подходили :) Да еще они хотели писать ОлеДб провайдер к своему СП :)
Я понимаю, что это очень полезно и интересно с точки зрения чистого програмизма, но когда мне нужен результат с точки зрения заказчика, сами понимаете.

2)Эксплуатация

2.1) Деплоймент изменений - каждое изменение в СП - это как минимум рестарт СП, возможно обновление всех клиентов. Зависит от фантазии разработчика.
При двузвенке - это просто прогрузка измененной процедуры. А если изменений несколько в день. Не пробовали? У вас наверное ежедневные билды и релиз раз в месяц? :)

2.2) Аудит системы, мониторинг производительности. В СУБД уже все есть ;)

2.3) Поиск нетривиальных ошибок в системе, да и тривиальных тоже. Врядли вы в своем СП реализуете, что-нибудь круче обычного SQL-Profiler. Хорошо если у вас есть хотябы БольшойПротокол работы СП.

2.4) Время безостановочной работы системы- как вы думаете, что проработает дольше глючный M$ SQL сервер или даже сто раз вылизанный самодельный СП?

2.5) Кто может поддерживать ваш СП? Только специально сертифицированные по вашему СП специалисты и разработчики. Первые и вторые это одни и те же люди? ;)

3) Зрелость
3.1) Хотели бы в 1980 году внедрять Оракыл у себя на предприятии? Когда еще не было РАДа, ОДБЦ и Оракыл падал и портил данные заказчиков:) Другими словами у меня глубокое ощущение, что идеи СП находятся сейчас примерно на той же стадии развития.

3.2) Поддержка со стороны поставщиков сред разработки.
Чтобы они не говорили об Архитектурах Систем Будущего, вытаскивать данные из СУБД в клиента умеют все и умеют хорошо.

3.3) Понимание со стороны разработчиков.
За годы клиент-серверной разработки выработались общепринятые приемы использования, с которыми знакомы все. В том числе люди готовые работать за 400 баксов. В области серверов приложений каждый изобретает свой велосипед. И долго будут еще изобретать, пока поставщики не договорятся до какого-то наименьшего общего знаменателя. Велосипеды приходится часто переделывать или вообще выкидывать, например когда поставщик скажет, что он ошибался и у него есть для вас лучшая технология.. Последнее время, кстати, они стали говорить это подозрительно часто.

3.4) Откуда берётся администратор для вашей системы?
Просто покупается на рынке и начинает делать свою работу? Покупается на рынке и учится с нуля? Какой вариант ваш?

3.5) Расскажите какой вы видите свою систему через 5 лет.
Наверное это вообще самый важный вопрос, когда рассуждаешь о зрелости технологии. Остальные вопросы, честно говоря, риторические - ответьте хотя бы на этот :)