Shakill_веб-приложение работает с базой ms sql, которую я сопровождаю. разработчик этого приложения осваивает и активно применяет Linq2Sql. с его слов, это гораздо удобнее при разработке, нежели использование хранимок, последующий разбор датасетов по объектам и прочее. а так как все это дело под веб, то проблем с распространением изменений не возникает

есть ли серьезные основания пытаться убедить разработчика отказаться от использования linq2sql, помимо того что я не могу влиять на оптимальность этих запросов?
Процедуры - это один из способов разделения уровней приложения.

Т.е. сервер - это не надёжно хранящийся массив байтов, а именно сервер - система, хранящая данные и отвечающая на запросы на получение и изменение данных от других систем.

СУБД отвечает за их целостность, оптимальность операций над ними и т.п. За неё отвечают отдельные специалисты. И интерфейс к СУБД - как раз процедуры. Больше на роль интерфейсов между уравнями ничего и нет.

Так же есть какой то сервер бизнес-логики, есть клиент - это всё отдельные компоненты. Хотя ведь можно сказать, что они тоже не нужны - приложение может и рисовать, и хранить данные, и содержать логику, и всё это на каком то мышкорисовательном средстве разработки.

Отрицать необходимость процедур то же самое, что вообще отрицать необходимость какого то разделения приложений на слои. Такое допустимо только для простых и короткоживущих приложений. В противном случае скоро наступает клинч - приложение нельзя будет безболезненно изменить.

В некоторых системах типа САП-а обычные процедуры не используются, но процедуры там всё равно есть, просто для этого сделан свой язык, среда выполнения и все необходимые инструменты.

Разработчик Linq2Sql, конечно, не может правильно оценить такие вещи, тут нужен архитектор, способный взглянуть на всё это шире, не как программист.

Chopalexeyvg...тут нужен архитектор, способный взглянуть на всё это шире, не как программист.+1
добавлю, и не как админ БД
вопрос в том, как приложение разделено по слоям
если бизнес-логика сидит на клиенте, то переносить ее на ХП - изврат чреватый многими неприятностямиЭто идеология разовых и маленьких программ. Конечно, если мы говорим про программы, работающие с базами данных.

Не разовые программы работают со многими БД, и много приложений работают с одной БД. Конечно, программисту клиента приятнее, что у него всё под контролем, но это всего лишь точка зрения программиста.

Просто не бывает чего то приличного без разделения на уровни. Не получится.

А выделение уровня в виде СУБД - это вполне доступный и нормальный путь.

ChopalexeyvgЭто идеология разовых и маленьких программ. Конечно, если мы говорим про программы, работающие с базами данных.гы...
1С тогда - разовая и маленькая программа? 1С как раз разделяет уровни. Вы наверное с ней не работали?

Там ведь бизнес-логика и работа с данными не пишется на том языке, на котором программируется клиент. Не смешивается всё в кучу.

Клиент и сервер приложений написан на С++, но при этом разработан свой внутренний язык, и никто этот код на С++ даже не видит. Работа с данными и прикладная логика пишется на внутреннем языке.

Отсутствие уровней - это если бы всё реализовавалось прямо на том языке, на котором разработан клиент (или сервер приложений), то есть на С++.

Так что 1С, как и любая приличная платформа, использует деление на уровне как по архитектуре, так и по программированию.

При этом в 1С не стали использовать СУБД как отделного уровня в системе.
Ну так и это добавляет гемороя - трудно поручить СУБД специалистам (ДБА или Database developers) решить проблемы с производтельностью и т.п. Идёт поток запросов и разбирайся как хочешь - для полноценной работы DBA должен обязательно быть хорошим специалистом в 1С

ViPRosalexeyvgТам ведь бизнес-логика и работа с данными не пишется на том языке, на котором программируется клиент. Не смешивается всё в кучу.

Клиент и сервер приложений написан на С++, но при этом разработан свой внутренний язык, и никто этот код на С++ даже не видит. Работа с данными и прикладная логика пишется на внутреннем языке.

ну и что? чем это Хорошо? если DSL полностью описывает DS, то вопросов нет. А что в 1С DS? и где DSL?Не знаю, где в 1С DS.

Это хорошо тем, что прикладному программисту легче разбираться в этом внутреннем языке. Даже если он не полностью описывает DS и если даже непонятно, что такое DS для 1С

Просто на С++ прикладные программисты ничего бы не писали и прикладных применений у 1С не было бы.