Сообщение Re[5]: EntityFramework - тормоз от 10.04.2015 11:57
Изменено 10.04.2015 11:59 _Case
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _Case, Вы писали:
_C>>Хорошо, а если рассмотреть следующую ситуацию ... — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..
S>Это называется "ложная альтернатива". То, что EF сосёт в таком сценарии, вовсе не означает, что кроме хранимок некуда податься.
S>Хранимки можно применять тогда, когда у вас вообше вся логика живёт в базе. В противном случае вы будете постоянно нарываться на рассогласование логики в backend и в хранимках. И на невозможность минимального рефакторинга без прогона долгих регрессионных тестов.
S>То, что обычные тяжеловесные ORM сосут, известно хорошо. Несосёт нормальный SQL. И тулзы по его построению вроде link2db. Потому что они не имеют проблем с версионированием вроде "ой, мы восстановили базу из бэкапа, и теперь у нас отчёты показывают какой-то бред". И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.
_C>>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..
S>Это у вас неправильный ORM.
_C>>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..
Спасибо! Я не был знаком с этим инструментов — link2db, я так понимаю это оно — https://github.com/linq2db/linq2db Почитаю, попробую поработать с этой библиотекой А так да, я пишу на .NET и обычно выношу всю логику в базу — внутрь хранимок, а на BackEnd-е максимум добавлял кэширование или вызов внешних API..
S>Здравствуйте, _Case, Вы писали:
_C>>Хорошо, а если рассмотреть следующую ситуацию ... — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..
S>Это называется "ложная альтернатива". То, что EF сосёт в таком сценарии, вовсе не означает, что кроме хранимок некуда податься.
S>Хранимки можно применять тогда, когда у вас вообше вся логика живёт в базе. В противном случае вы будете постоянно нарываться на рассогласование логики в backend и в хранимках. И на невозможность минимального рефакторинга без прогона долгих регрессионных тестов.
S>То, что обычные тяжеловесные ORM сосут, известно хорошо. Несосёт нормальный SQL. И тулзы по его построению вроде link2db. Потому что они не имеют проблем с версионированием вроде "ой, мы восстановили базу из бэкапа, и теперь у нас отчёты показывают какой-то бред". И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.
_C>>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..
S>Это у вас неправильный ORM.
_C>>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..
Спасибо! Я не был знаком с этим инструментов — link2db, я так понимаю это оно — https://github.com/linq2db/linq2db Почитаю, попробую поработать с этой библиотекой А так да, я пишу на .NET и обычно выношу всю логику в базу — внутрь хранимок, а на BackEnd-е максимум добавлял кэширование или вызов внешних API..
Re[5]: EntityFramework - тормоз
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, _Case, Вы писали:
_C>>Хорошо, а если рассмотреть следующую ситуацию ... — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..
S>Это называется "ложная альтернатива". То, что EF сосёт в таком сценарии, вовсе не означает, что кроме хранимок некуда податься.
S>Хранимки можно применять тогда, когда у вас вообше вся логика живёт в базе. В противном случае вы будете постоянно нарываться на рассогласование логики в backend и в хранимках. И на невозможность минимального рефакторинга без прогона долгих регрессионных тестов.
S>То, что обычные тяжеловесные ORM сосут, известно хорошо. Несосёт нормальный SQL. И тулзы по его построению вроде link2db. Потому что они не имеют проблем с версионированием вроде "ой, мы восстановили базу из бэкапа, и теперь у нас отчёты показывают какой-то бред". И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.
_C>>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..
S>Это у вас неправильный ORM.
_C>>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..
Спасибо! Я не был знаком с этим инструментом — link2db, я так понимаю это оно — https://github.com/linq2db/linq2db Почитаю, попробую поработать с этой библиотекой. А так да, я пишу на .NET и обычно выношу всю логику в базу — внутрь хранимок, а на BackEnd-е максимум добавлял кэширование или вызов внешних API..
S>Здравствуйте, _Case, Вы писали:
_C>>Хорошо, а если рассмотреть следующую ситуацию ... — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..
S>Это называется "ложная альтернатива". То, что EF сосёт в таком сценарии, вовсе не означает, что кроме хранимок некуда податься.
S>Хранимки можно применять тогда, когда у вас вообше вся логика живёт в базе. В противном случае вы будете постоянно нарываться на рассогласование логики в backend и в хранимках. И на невозможность минимального рефакторинга без прогона долгих регрессионных тестов.
S>То, что обычные тяжеловесные ORM сосут, известно хорошо. Несосёт нормальный SQL. И тулзы по его построению вроде link2db. Потому что они не имеют проблем с версионированием вроде "ой, мы восстановили базу из бэкапа, и теперь у нас отчёты показывают какой-то бред". И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.
_C>>Ещё пример — сложные отчеты, по моему опыту через ORM такой отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое количество времени..
S>Это у вас неправильный ORM.
_C>>Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..
Спасибо! Я не был знаком с этим инструментом — link2db, я так понимаю это оно — https://github.com/linq2db/linq2db Почитаю, попробую поработать с этой библиотекой. А так да, я пишу на .NET и обычно выношу всю логику в базу — внутрь хранимок, а на BackEnd-е максимум добавлял кэширование или вызов внешних API..