Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, gandjustas, Вы писали:

НС>>>Чтобы писать код не задумываясь о деталях реализации ORM. Сейчас таких ORM нет.
G>>В первую очередь нужно задумываться о той СУБД, для которой пишешь.

НС>И это тоже. Но, по опыту, работать на разных СУБД все таки намного проще, чем работать на разных ORM. Первое у меня еще получалось, а вот второе — никогда. Даже переезд с blt linq на linq2db на крупных проектах совсем нетривиальная задача.

У меня опыт ровно обратный, не было проблем при переключении между Linq2SQL\EF\NHibernate, большинство запросов не меняются, разница в мелочах, которые отлично прячутся в Extension-методы. А вот когда надо было адаптировать код для SQL Server под SQLCE пришлось потрахацца.

НС>>>Проблема не в транслируемости конструкций, а в том что вполне осмысленные, нормально выглядящие и работающие на linq2objects конструкции на SQL фик переведешь.
G>>Обратное также верно.
НС>Да не особо. Приведенные тобой примере это точно не доказывают.
Ты везде сводишь к тому, что можно написать свои функции и потом их както мапить. Вот только с ranking function ничего хорошего не получается, увы. Особенно если надо сохранить семантику, чтобы аналогичный запрос для linq2objects работал.

НС>>>СТЕ сама по себе линку просто не нужна. А поддердка рекурсии — вопрос конкретных провайдеров, которым просто никто не занимался всерьез.
G>>В linq нет средств для рекурсии.

НС>Т.е. с CTE без рекурсии вопросов нет? А средства для рекурсии есть, просто их придется иначе выражать. Идея проста:
Без рекурсии просто подставляется одно выражение в другое.

НС>Но это так, мелочь. Куда интереснее другое — рекурсия в SQL в 99% случаев используется для запросов по деревьям. А запросы по деревьям на линке выражаются вообще без рекурсии, потому что линк плоской моделью не ограничен. Т.е. на линке в модели дерево можно описать сразу деревом, а рекурсивные запросы пусть строит провайдер.
В линке нет готовых средств для обхода деревьев, все решается через кастомные комбинаторы. Но в SQL семантика рекурсии другая и парой комбинаторов не обойдешься.

G>>>>3) MERGE-оператор
НС>>>Тоже не проблема.
G>>Что значит "не проблема" ?
НС>То и значит что на линке это легко выражается, просто существующие провайдеры такое не умеют.
Ох сомневаюсь что ты сможешь адекватно для Linq написать MERGE чтобы покрыть все возможности оператора.

G>>Увы в linq таких средств нет
НС>Ты query comprehension с linq не путаешь? В QC и DML нет, а в linq провайдерах оно таки есть.
Не путаю, покажи ranking functions в любом провайдере.

НС>>>При этом есть несколько моментов, которые действительно несколько фигово в линке выражаются по сравнению с сиквелом. Но ни один из них ты не упомянул.
G>>То что ты не видишь не значит что их нет.
НС>Ну так давай, рассказывай. А то тот же PIVOT/UNPIVOT, который легко описывается extension методом явно на такое не тянет.
Покажи пример.

НС>>>Эрик? Ссылку можно? А то я немножко на эту тему с ним общался, и ничего подобного не услышал.
G>>Это очень давно было, сейчас не найду даже.

НС>Я примерно такое и ожидал. Скорее всего ты просто неверно понял — наоборот, выразительные возможности линка больше, и это создает серьезные проблемы. Потому что люди, не искушенные в специфике провайдеров линка пишут вполне логичные запросы, которые нормально оттранслировать не выходит. Даже я, будучи в теме, изредка натыкаюсь на такое.
Ты куда-то в сторону ушел.
Вот что я говорил:
1) Мейер на Haskell создавал систему, которая позволяет код транслировать в SQL (это факт)
2) Мейер эту идею принес в C# (это он говорил, можно попробовать на Channel9 найти это видео)
3) Все пляски с Expression Trees и linq-comprehensions сделаны только для трансляции запросов в SQL. В других языках есть query comprehensions, которые гораздо лаконичнее с такой же выразительной силой.
У тебя есть возражения?

То что не любое дерево выражений можно перевести в SQL я и не спорил. Во-первых внутри ET можно написать любое выражение языка, например создание несериализуемых объектов. Во-вторых linq работает с последовательностям, а SQL с множествами, разница в семантике делает многие linq выражения бессмысленными в SQL. Но оба эих факта никаким образом не связаны с выразительной силой.
Фактически выразительная сила — возможность получить больше результатов выражений, используя меньше кода. Если мы рассматриваем работу с данными, то Linq, увы, в не дотягивает до SQL.