Ребят, а Entity Framework и высокопроизводительные запросы к БД это

Смотря как его использовать. EF довольно-таки неоптимальные SQL-запросы генерирует и много чего не умеет из того, что можно сделать на чистом SQL. Но это не проблема одного EF, это проблема любого ORM. В итоге, когда есть требование к высокой производительности в сильно нетривиальных запросах и на очень больших массивах данных, я пишу вьюхи и table-valued функции, и уже их прокидываю в EF. На уровне чистого SQL можно оптимизировать планы запросов, а при генерации чёрт знает какого SQL фреймворком это нереально. Как яркий пример - это "оконные функции" и сегментирование данных, которые позволяют очень быстро на уровне SQL решать целый класс задач (первые или последние значения в группах, выделение только изменённых данных по сравнению с предыдущим значением, нарастающий итог, сумма по n предыдущих значений, ...) и это невозможно эффективно выразить на уровне ORM. Если для таких вычислений использовать классический SQL без оконных функций - скорость и расход памяти будут на порядки хуже. А ещё есть такие вещи как PIVOT/UNPIVOT, рекурсивные запросы (через CTE). ORM-ы хороши для запросов и обновления чётко определённых сущностей по одной. Когда дело доходит до массированных вычислений на больших наборах данных и до массированных обновлений данных - без чистого SQL нечего делать, а в особо жестоких случаях (вставка больших объёмов данных) даже SQL не катит, надо делать BULK INSERT.

0

29.05.2018

Ɓ◒◓дь моим смыслом · Accepted Answer

Ɓ◒◓дь моим смыслом

dapper

0

29.05.2018

170 похожих чатов

Ребят, а Entity Framework и высокопроизводительные запросы к БД это

4 ответов

Похожие вопросы