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

K>Давно мучает вопрос по этому поводу. Если у меня есть более-менее серьёзный запрос к базе данных я делаю пользовательскую табличную функцию с параметрами и ложу её на сервер, где помещаю всё логику по выборке данных. От Linq мне тут надо только чтобы, он мне объект по результатам создал, но это и так давно умеют делать и без него. Потом мне гораздо проще менять SQL код, если чего не так, чем исходники. Вот и не понятно, чего это носятся все с этим linq.

У тебя отдельный подход. Он конечно тоже имеет право на лево... тфу ты, жизнь . Однако у него есть свои достоинства и недостатки.
Мы можем получить от использования ЛИНК-а?
1. Поддержку интелисенса. Это повзоляет писать код быстрее и качественее. Так же это позволяет быстро и без проблем рефакторить код. Несмоненно тоже можно сделать для конкретного диалекта SQL, но ведь почему-то качественно это не сделано.
2. Проверку выражений на стадии компиляции. Это позволяет раньше выявлять общики, а чем раньше выявлена ошибка, тем проще ее устранить.
3. Поддержку разных источников данных. По мощьности ЛИНК-запросы, а темболее в купе с Шарпом, Васиком или темболее Немерле мягко говоря не уступают возможностям императивных расширений SQL-я вроде TSQL (MS) или PSQL (Oracle). Более того у ЛИНК-а отсуствуют некоторые ограничения вроде уровней рекурсии процедур и т.п. Так что для написания прикладной логики ЛИНК подходит даже лучше чем TSQL/PSQL. При этом код получается кросплатформным. Ну, или по крайней мере его будет намного проще сделать таковым.
4. Линк позволяет использовать в качестве источника данных не только БД, но и другие источники (коллекции объектов, ХМЛ, датасеты и т.п.). Это позволяет реализовывать неординарную логику используя один диалект языка запросов.
5. Линк позволяет осуществлять часть обработки вне СУБД. Это повзяоляет разгрузить СУБД и тем самым повысить производительностить и мастабируемость решений.

В конце концов, если уж очень приспичет, всегда можно создать хранимые процедуры или фунции которые вызвать с помощь Линка и которые будут возвращать уже обработанные данные. Но при этом мы теряем перечисленные приемущества (возможно получаях что-то другое взамен). Но это друной подход, а речь в данном случае была связана с ОР-Мапперами.

K>Хотя, конечно, если это не SQL провайдер, то может имеет смысл, но всё равно для XML, например, имхо часто вполне хватало XPath.

Согласен. Но XPath не встроен в язык вроде Шарпа. Надо понимать, что Линк-запросы — это не SQL. Это похожий на SQL язык. Но его база — это фунциональное программирование, т.е. декомпозиция запроса на вызов нескольких фуцний получающих критерии в качестве параметров (в виде фунций-лямбд). Таким образом это универсальный язык обработки данных. Наверно можно было бы облачить его в форму XPath, но выбран был именно SQL. Видимо потому, что он лучше ложится на фунциональную декомпозицию.

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