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

ARK>Ну да, именно их и использовал. Жаль, что нет. По-моему, есть случаи, когда эти методы заменить нельзя — скаляр какой-нибудь получить, например...

А чем тебе линк для получения скаляра не подходит?

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

VC>Весь критический по требованиям производительности тормозам код приходится переписывать выкидывать с помощью Dapper.

VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Entity Framework полезен когда нужно работать с локальной embedded базой (SqLite, SQL Compact) в desktop приложении, потому как писать inline SQL код (в C# классах) не очень удобно и чревато ошибками типа — забытой кавычки, а хранимых процедур в таких встроенных движках баз нет, а для WEB согласен, на хранимках сайт работает гораздо быстрее (при работе с MSSQL Server IMHO на порядки)

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

_C>Entity Framework полезен когда нужно работать с локальной embedded базой (SqLite, SQL Compact) в desktop приложении, потому как писать inline SQL код (в C# классах) не очень удобно и чревато ошибками типа — забытой кавычки, а хранимых процедур в таких встроенных движках баз нет, а для WEB согласен, на хранимках сайт работает гораздо быстрее (при работе с MSSQL Server IMHO на порядки)
Facepalm. Вы просто не умеете готовить батчи.
Хранимки к перформансу не имеют почти никакого отношения.

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

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

_C>>...на хранимках сайт работает гораздо быстрее (при работе с MSSQL Server IMHO на порядки)
S>Хранимки к перформансу не имеют почти никакого отношения.
Хранимки к перформасу скорее обратное отношение имеют при таком уровне рассуждений.

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

Н>>А вы продолжайте вручную выпиливать "select * from ...", склеивать строки и заниматься "... and (@p is null or foo.Bar = @p) ...".
С>Linq2DB достаточен для работы с БД.

Linq2DB явно избыточное решение, склейки строк достаточно для работы с БД.

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

G>А select * и неустойчивый план это нормально?
А в чем отличие * от перечисления полей?

А план неустойчивый из-за Null'а Or "=" ? А какой вариант в этой ситуации предложешь?

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

_C>Entity Framework полезен когда нужно работать с локальной embedded базой (SqLite, SQL Compact) в desktop приложении, потому как писать inline SQL код (в C# классах) не очень удобно и чревато ошибками типа — забытой кавычки, а хранимых процедур в таких встроенных движках баз нет, а для WEB согласен, на хранимках сайт работает гораздо быстрее (при работе с MSSQL Server IMHO на порядки)

Я тут изредка переписываю на этом сайте хранимки на линк. И вот что удивительно — еще ни разу перфоманс не упал, зато подрастает он почти всегда. Был даже случай, перфоманс вырос в 3 раза.

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

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

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

FLY>А план неустойчивый из-за Null'а Or "=" ? А какой вариант в этой ситуации предложешь?
Предложу вариант логику формирования предикатов вынести в приложение. Ты же в приложении знаешь будет у тебя параметр null или нет.
Тогда в приложении пишешь:

IQueryable<X> ApplyParamY(IQueryable<X> source, Y y)
{
    return y==null?source:source.Where(x => x.Y == y.Value);
}

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

Вот тут было — http://gandjustas.blogspot.com/2014/09/asp.net-linq-ef-sql-server-performance.html

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

G>select * запрашивает метаданные, что заметно влияет на время.

А там что-то отличное от

select column_name from information_schema.columns where ....

?

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

Y>Linq2DB явно избыточное решение, склейки строк достаточно для работы с БД.

Вай-вай, как толсто.

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

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

G>>select * запрашивает метаданные, что заметно влияет на время.

Y>А там что-то отличное от

select column_name from information_schema.columns where ....

?

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

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

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

_C>>Entity Framework полезен когда нужно работать с локальной embedded базой (SqLite, SQL Compact) в desktop приложении, потому как писать inline SQL код (в C# классах) не очень удобно и чревато ошибками типа — забытой кавычки, а хранимых процедур в таких встроенных движках баз нет, а для WEB согласен, на хранимках сайт работает гораздо быстрее (при работе с MSSQL Server IMHO на порядки)
S>Facepalm. Вы просто не умеете готовить батчи.
S>Хранимки к перформансу не имеют почти никакого отношения.

Хорошо, а если рассмотреть следующую ситуацию — допустим пользователь по нажатию кнопки на сайте запускает некую сложную (не просто MERGE / UPDATE) процедуру пересчета данных за определенный период времени, например за месяц, алгоритм может использовать большое количество (десятки — сотни тысяч записей) из нескольких таблиц, если это реализовать хранимой процедурой (даже если в ней будут использоваться и курсоры и ещё что-то) — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..

Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..

Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..

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

G>select * запрашивает метаданные, что заметно влияет на время. Но проблема не в этом, а в том, что ты тянешь поля, которые не используешь. Это повышает нагрузку на базу, сеть, приложение, и, самое главное, не позволяет построить покрывающий индекс.
Если нужно одно или пару полей понятно что не будешь использовать *, а вот если нужно тянуть все поля или почти все, например из 20 нужно 16, что все перечислять?

G>Предложу вариант логику формирования предикатов вынести в приложение. Ты же в приложении знаешь будет у тебя параметр null или нет.
G>Тогда в приложении пишешь:
G>

G>IQueryable<X> ApplyParamY(IQueryable<X> source, Y y)
G>{
G>    return y==null?source:source.Where(x => x.Y == y.Value);
G>}
G>

G>У тебя получаются разные запросы по разным комбинациям параметров и ты можешь построить разные индексы, которые разные ускоряют разные запросы.
Если я правильно понимаю, в таком случае каждый раз когда запрос отправляется на сервер будет строится план, верно? Все равно лучше чем уже имеющийся нестабильный?

G>Причем если у тебя таблица большая и очень разряженая, то можно использовать фильтрованные индексы, офигенно добавляют скорости.
G>Вот тут было — http://gandjustas.blogspot.com/2014/09/asp.net-linq-ef-sql-server-performance.html
Спасибо, почитаю.

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

_C>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..

Если под отчетом подразумевается набор строчек в некоторой таблице, которые получены путем агрегирования множества строк из других таблиц, то на LINQ можно просто написать INSERT-FROM-SELECT запрос со всеми джойнами, он исполнится на сервере и не станет передавать никаких избыточных данных между клиентом и сервером. Только EntityFramework этого просто не умеет. Среди известных мне инструментов, такое может только linq2db и JOOQ.

К сожалению, LINQ для батчей с курсорами, переменными, временными таблицами и прочей императивщиной еще не написали. И вообще непонятно, как его писать — процедурные диалекты у СУБД сильно отличаются.

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

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

G>>select * запрашивает метаданные, что заметно влияет на время. Но проблема не в этом, а в том, что ты тянешь поля, которые не используешь. Это повышает нагрузку на базу, сеть, приложение, и, самое главное, не позволяет построить покрывающий индекс.
FLY>Если нужно одно или пару полей понятно что не будешь использовать *, а вот если нужно тянуть все поля или почти все, например из 20 нужно 16, что все перечислять?
Конечно. И Linq кстати в этом прекрасно помогает.


G>>У тебя получаются разные запросы по разным комбинациям параметров и ты можешь построить разные индексы, которые разные ускоряют разные запросы.
FLY>Если я правильно понимаю, в таком случае каждый раз когда запрос отправляется на сервер будет строится план, верно? Все равно лучше чем уже имеющийся нестабильный?
Нет, план строится только при первом запросе, потом кешируется, соответственно планов у тебя будет как 2^n параметров, что в принципе немного. И это в разы лучше, чем иметь нестабильный план, который, по факту, хреново подходит для всех запросов, кроме изначальной комбинации параметров.

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

_C>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..
А зачем отчеты с помощью ORM делать? Чтобы при изменении отчета деплоить новую версию приложения?

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

_C>Хорошо, а если рассмотреть следующую ситуацию ... — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..
Это называется "ложная альтернатива". То, что EF сосёт в таком сценарии, вовсе не означает, что кроме хранимок некуда податься.
Хранимки можно применять тогда, когда у вас вообше вся логика живёт в базе. В противном случае вы будете постоянно нарываться на рассогласование логики в backend и в хранимках. И на невозможность минимального рефакторинга без прогона долгих регрессионных тестов.
То, что обычные тяжеловесные ORM сосут, известно хорошо. Несосёт нормальный SQL. И тулзы по его построению вроде link2db. Потому что они не имеют проблем с версионированием вроде "ой, мы восстановили базу из бэкапа, и теперь у нас отчёты показывают какой-то бред". И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.

_C>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..
Это у вас неправильный ORM.
_C>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..

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

Y>Linq2DB явно избыточное решение, склейки строк достаточно для работы с БД.
Храбрых путь выбрал ты. Жаль, что недолог он.

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

Y>>Linq2DB явно избыточное решение, склейки строк достаточно для работы с БД.
S>Храбрых путь выбрал ты. Жаль, что недолог он.

Еще как долог. До всех этих ORM какие только велосипеды не велосипедировали, а всё равно приходилось если не в коде клеить, то в хранимке и exec()... Переименовать столбец — так вообще задача для самоубийц.
Как вспомню так вздрогну.

Здравствуйте, Yoriсk, Вы писали:
Y>Еще как долог. До всех этих ORM какие только велосипеды не велосипедировали, а всё равно приходилось если не в коде клеить, то в хранимке и exec()... Переименовать столбец — так вообще задача для самоубийц.
Может, пора подумать о Linq2db?
Y>Как вспомню так вздрогну.
И я о том.