Здравствуйте, DuШes, Вы писали:

DШ>Здравствуйте, Lloyd, Вы писали:

DШ>[...]

L>>Как я понял из сообщения топикстартера, его начальство надеялось получить прирост производительности путем тупого переноса sql-я, генерируемого LINQ2SQL-ем, в хранимые процедуры. О ручном тюнинге sql-я речи и не было.

DШ>да я собственно и не спорю...соглашусь с вашим постом, что прироста производительности не будет, речь даже не о том, что sql сервер умеет кешировать не только скомпилированные планы процедур, но также и вызовы простых запросов.

DШ>вообще, желание нормальное — увеличить производительность — но трудозатраты очень большие, даже не только потому, что тупо перенести запросы в процедуры не получится, придется переделывать вообще механизм доступа к данным и думать о тех orm классах, которые были сгенерированы на основе таблиц...

DШ>в той постановке задачи, которая присуствует сейчас, самая большая проблема следующая:
DШ>желание оставить классы сгенерированной схемы и работать с ними будет затруднительно, потому что не каждая хранимка (метод схемы) будет возвращать тот набор полей, которые потребуется для маппинга в сгенерированные классы, иначе, придется ручками описывать те классы, которые ранее нам генерировал компилятор для анонимных типов

DШ>вообще на мой взгляд или работать с linq по старому без процедур или не работать вообще, иначе сразу можно застрелиться

А почему для всех свет клином сошелся на процедурах? Есть много других средств инкапсуляции в SQL, есть View, которыя для запросов подходят гораздо лучше процедур, есть instead of триггеры, которые позволяют работать с вьюхами, как с таблицами.
Я вообще не вижу смыла делать CRUD на процедурах.

И никакого геморроя потом в программе не появляет, можно использовать все тот же Linq\EF.