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

IT>Вопрос генерации эффективного SQL — это дело техники. Никаких принципиальных ограничений на это нет. Например, пейдджинг практически для всех БД реализован по разному, именно так, как это более эффективно для конкретной БД. Тоже самое с InsertOrUpdate. Есть другая проблема. Некоторые БД не подддерживают некоторые возможности, как, например, Sybase не поддерживат TOP в подзапросах. В результате один и тот же linq запрос где-то будет работать, а где-то не очень. В этом случае придётся разруливать всё вручную.

Это зависит от уровня абстракции ORM. Если мы имеем тяжёлую ORM (в которой весь код имеет вид db.persist(obj); ), то т.к. она полностью скрывает весь вид запросов внутри себя, то в принципе можно всю зависимость от вида СУБД там и оставить (с другой стороны такие ORM не особо эффективны сами по себе, вне зависимости от переносимости). Если же мы имеет дело с лёгкой ORM (где активно используется sql синтаксис), то уже можно очень легко наткнуться в прикладном коде на особенности конкретных СУБД.

IT>Слой абстракции БД может нести в себе две функции: абстракцию от БД и абстракцию вообще. Если всё сделано ради первого, а не ради второго, то с использованием linq слой абстракции БД не нужен. При этом при его устранении происходит существенное упрощение приложения:

Я согласен. Linq, как пример лёгкой ORM вполне себе осуществляет абстракцию от СУБД. Более того, у него есть свои модные плюсы. Но есть и минусы:

1. Т.к. это лёгкая ORM, то всё же можно в прикладном коде наткнуться на разную обработку запросов разными СУБД.
2. У linq не всё в порядке с эффективностью. Уже в смысле накладных расходов, а не особенностей sql. Что собственно и обсуждалось в данной теме.

IT>Про главное и самое могучее преимущество linq перед плоским SQL — type-safety, я вообще молчу.

Конечно. Но в этой теме опять же показывали, что возможна статическая типизация sql запросов без накладных расходов.