Существуют ли какие-либо операции, которые ORM не может обработать, и требуется использование SQL?

Question

Фон

Я уже использую Entity Framework + Linq около года, и у меня не было ни одного случая, когда предложения SQL были бы -required-. Конечно, могли быть вещи, которые опытный писатель SQL мог бы делать быстрее, но я ищу вещи, которые невозможно или очень сложно сделать с ORM.

Вопрос

Мой вопрос (для удовлетворения моего любопытства) заключается в том, какие операции / ситуации ORM в целом не могут обрабатывать?

У меня мало знаний о базах данных, но разве не так, что если вы хотите удалить все содержимое из одной таблицы, то, по крайней мере, в Entity Framework вам придется зацикливать элементы, которые вы хотите удалить.

Спасибо за вашу информацию

Резюме Похоже, что команды, зависящие от производительности и производителя, являются причиной, по которой ORM нельзя использовать (готово)

Answer 1

Мне еще не приходилось сталкиваться с ORM, который может делать то, что вы можете делать с аналитическими запросами Oracle.(Они стали частью стандарта SQL 2003 и находят свой путь в другие базы данных.) См. http://www.orafaq.com/node/55 для ознакомления с аналитическими запросами.

Существуют также тонкости вокруг левых объединений, которые я обычноне вижу выставленных в ORM, но я не знаю Linq, и он может иметь их.Например, сравните

SELECT ...
FROM foo
  LEFT JOIN bar
    ON bar.bar_id = foo.bar_id
      AND bar.category_id = 5
  LEFT JOIN baz
    ON baz.baz_id = bar.bar_id
  ;

с

SELECT ...
FROM foo
  LEFT JOIN bar
    ON bar.bar_id = foo.bar_id
  LEFT JOIN baz
    ON baz.baz_id = bar.bar_id
      AND bar.category_id = 5
  ;

Может ли Linq правильно выразить оба запроса?

Answer 2

По моему опыту, всегда бывают ситуации, когда лучше написать сам SQL, а не позволить инструменту ORM генерировать SQL.Я бы хотел этого избежать, но в некоторых случаях ORM не может генерировать наиболее эффективный SQL для некоторых сложных запросов.

Фактически, когда я использую собственный SQL вместо того, чтобы позволить ORMИспользование (NHibernate) делает работу, в основном из-за проблем с производительностью.
Тем не менее, NHibernate делает действительно хорошую работу по генерации наиболее производительного SQL-кода из возможных, поэтому необходимость написания самого SQL на самом деле встречается редко.

Answer 3

При наличии надлежащего ORM с открытым исходным кодом, ORM, вероятно, можно изменить, чтобы генерировать любой SQL, какой вы хотите, в любом сценарии, который вы хотите против любого поставщика базы данных.

Итак, хотя ни одна ORM из коробки, вероятно, не имеет 100% покрытия того, что вы можете сделать с SQL (особенно SQL, специфичный для поставщика базы данных / нестандартный), на самом деле нет технической причины, по которой ORM не может быть изменены для этого.

Функциональные выпуски Entity Framework и Linq не очень гибки, так что они потенциально медленнее адаптируются к тому, что хотят пользователи ORM. Тем не менее, Linq (не LinqToSql) был отличным дополнением к миру ORM.