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

НС>>Почему?
G>Потому что надо внутри select генерировать order by и ROWS clause.

Это не проблема.

G> Это будет аццкий монстр в виде linq.

Не думаю.

НС>>В линке вообще нет готовых средств. Средства предоставляют конкретные провайдеры.
G>После этого ты утверждаешь что linq выразительнее?

Да.

НС>>Это Мейер говорил? Ты точно в этом уверен? Потому что когда я с ним разговаривал, он говорил совсем иное.
G>Нет, это по факту.



G> С момента появления linq прошло более 5 лет, но до сих пор кроме трансляции в SQL достойных применений у ET практически нет.

Тебе так кажется. Тот же МСовский клиент к odata. У полнотекстовых движков и поисковиков провайдеры бывают. У NoSQL, опять же, без этого обычно не обходится. Просто задача общения с РСУБД настолько огромная, что затмевает все остальное.

НС>>Не не не. Ты давай расскажи, где это Мейер рассказывал что выразительность у линка меньше, чем у SQL.
G>Я не говорил что Мейер это рассказывал.

G>>> Linq создавался как раз чтобы не сильно отставать по выразительности от SQL.
НС>>Это ты сам придумал?
G>Нет, об этом Мейер говорил.

НС>>Это мелочь. Проблема не в этом. А вот то что легко написать GroupBy, который придется транслировать в килограмм запрросов — вот это уже конкретная проблема выразительности SQL.
G>И ниже ты пишешь что linq не работает с последовательностями.

Прочти внимательнее что я пишу. Вот ключевая фраза: "Последовательности для линка — лишь частный случай."

G>Мы сейчас говорим об IQueryable<T>

С чего ты взял?

G>Так вот GroupBy, возвращает специальный вид последовательности — IGrouping,

IGrouping это не просто последовательность, это дерево.

G> а SQL не знает о таком, у него на выходе всегда реляция (таблица)

Ну вот, ты и сам все по поводу выразительности SQL понимаешь.

G>. Но это совершенно не значит, что SQL обладает меньшей мощностью

Именно это это и значит. Средства SQL не позволяют удобно работать с деревьями, даже совсем простыми.

G>, он умудряется без специальных типов последовательностей реализовывать то же самое

В том то и проблема, что не умудряется. Только совсем примитивные случаи, когда вложенная последовательность сворачивается в небольшой набор агрегатов. Если же дерево свернуть не удается, то все, приплыли, выразительность SQL закончилась.

G>, когда SQL обходится несколькими дополнительными функциями.

Ну давай, продемонстрируй выразительность SQL на простеньком запросике:

db
  .Messages
  .Select(
    m =>
      new
      {
        m.Id,
        Rates = m.Rates.Where(r => r.MessageId = m.Id && r.Type == RateType.Positive),
        Replies = db.Messages.Where(sm => sm.ParentId = m.Id)
      })

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

Я уже обосновал.

НС>>Угу. И уже одна возможность не писать в линке большую часть джойнов вполне себе наглядно демонстрирует, какой из языков выразительнее.
G>О да, неявное вписывание left join по ключу это конечно выразительной силы добавляет.

Почему обязательно left join? И да, добавляет. Некоторые запросы сокращает в разы. Если это не выразительность, то я даже и не знаю что ты за нее принимаешь.

G> Это наверное единственное преимущество выразительности linq перед sql.

Не единственное. Но ты согласен что линк выразительнее хотя бы в этом?

НС>>А если к тому добавить убогость и громоздкость CTE по сравнению с простейшими способами декомпозиции в линке, то я вообще не понимаю как можно не видеть очевидного.
G>Тем не менее CTE позволят делать рекурсивные запросы, а linq нет.

Потому что линку это ненужно.

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

С тобой все понятно.