Comments 21
Для некоторых платформ, это совсем не мифы :)
Могу сказать, что в Windows Phone это чистая правда. Так как, там не реализован Emit, то маппинг происходит исключительно за счет рефлексии.
Так же там база не поддерживает кеширование и все запросы всегда выполняются на базе.
Миф №3
Медленно работает маппинг.
Могу сказать, что в Windows Phone это чистая правда. Так как, там не реализован Emit, то маппинг происходит исключительно за счет рефлексии.
Так же там база не поддерживает кеширование и все запросы всегда выполняются на базе.
Извините за чайниковский вопрос в двух вариантах — допустим, у нас есть маленькая домашняя бухгалтерия:
вариант первый — телефон подключен к сети, есть клиентское приложение — кто мешает облегчить все и вынести все тяжелое на сервер?
вариант второй — телефон не подключен в сети — командировка, отпуск, другая страна, интернет отсутствует/дорогой — работа с кешированными данными только оффлайн, синхронизация с какой-то периодичностью (бесплатная сеть в отеле вечером)
ну и в день, я допустим совершаю несколько раз перекусить, проезды, покупка сувениров, музеи всякие…
Честно, я не очень понимаю, какие гигантские объёмы данных в телефон должны быть, чтобы это сильно отражалось на производительности и быстроте разряда того же WP.
вариант первый — телефон подключен к сети, есть клиентское приложение — кто мешает облегчить все и вынести все тяжелое на сервер?
вариант второй — телефон не подключен в сети — командировка, отпуск, другая страна, интернет отсутствует/дорогой — работа с кешированными данными только оффлайн, синхронизация с какой-то периодичностью (бесплатная сеть в отеле вечером)
ну и в день, я допустим совершаю несколько раз перекусить, проезды, покупка сувениров, музеи всякие…
Честно, я не очень понимаю, какие гигантские объёмы данных в телефон должны быть, чтобы это сильно отражалось на производительности и быстроте разряда того же WP.
Надо исходить от требований. Если требование показывать статистику, красивые графику и быструю работу в оффлайне, то придется реализовывать оффлайн. Если требование просто показывать информацию, то можно обойтись чисто онлайном с выводом ошибок, что не удалось подключиться и прочее.
Но вопроса до конца так и не понял, насчет разрядки, зависит не от объема данных, а от времени работы CPU. Некоторые даже используют DirectX для отображения графиков, что тоже сказывается на заряде батареи.
Но вопроса до конца так и не понял, насчет разрядки, зависит не от объема данных, а от времени работы CPU. Некоторые даже используют DirectX для отображения графиков, что тоже сказывается на заряде батареи.
>Но во всех провайдерах такой анализ проводится один раз, а потом данные кешируются.
Для L2SQL нужно использовать CompiledQuery — т.е. сам провайдер не кеширует — чтобы анализ происходил только 1 раз.
Для EF провайдер кеширует только на время открытия контекста, т.е. разбор linq дерева будет повторятся множество раз (если не воспользоваться тем же фокусом как и в l2sql).
Возможно, я вас неправильно понял или неправ)
Для L2SQL нужно использовать CompiledQuery — т.е. сам провайдер не кеширует — чтобы анализ происходил только 1 раз.
Для EF провайдер кеширует только на время открытия контекста, т.е. разбор linq дерева будет повторятся множество раз (если не воспользоваться тем же фокусом как и в l2sql).
Возможно, я вас неправильно понял или неправ)
Иногда генератор SQL-я работает совершенно неисповедимо: stackoverflow.com/questions/5205281/very-different-performance-of-ef-with-very-similar-queries
Прежде чем писать такой код, почитайте предыдущий пост — habrahabr.ru/post/230479/
Тот код был написан 3 года назад. Не очень понимаю какой совет из предыдущего поста мне бы там помог? Для меня непонятно как генератор из такого элементарного выражения нагородил тот огород который там приведен в вопросе:
var scope = model.Scopes.Include("Settings")
.Where(s => (s.Level == intLevel && s.Name == name))
.First();
В SQL Server есть механизм Plan Guide, который позволяет навесить хинты на любой запрос.
Он позволит навесить WITH(NOLOCK) на одну из таблиц, используемых в запросе?
да, но лучше изучите другие варианты.
А что будет если обновится EF, и начнет немного по-другому строить запросы. Все мои plan guides придется переписать?
Если будет много plan guides, то проблема вовсе не в ef.
Еще раз повторю слова поста — Linq позволяет описать только очень простые запросы, которые прекрасно оптимизируются SQL Server и Oracle. Если СУБД не оптимизирует запрос, то значит не хватает индексов\статистики\ограничений. Поэтому хинты вряд ли нужны будут. NOLOCK тоже не нужно ставить, лучше запросы оптимизировать, чтобы интервал блокировок был меньше. На крайний случай установить уровень изоляции read uncommitted. А в идеале поставить RCS.
Еще раз повторю слова поста — Linq позволяет описать только очень простые запросы, которые прекрасно оптимизируются SQL Server и Oracle. Если СУБД не оптимизирует запрос, то значит не хватает индексов\статистики\ограничений. Поэтому хинты вряд ли нужны будут. NOLOCK тоже не нужно ставить, лучше запросы оптимизировать, чтобы интервал блокировок был меньше. На крайний случай установить уровень изоляции read uncommitted. А в идеале поставить RCS.
А как решается задача удаления объектов из таблицы/таблиц по каким-нибудь критериям?
Требуется ли для этого сначала эту коллекцию прочитать?
Требуется ли для этого сначала эту коллекцию прочитать?
По поводу первого мифа:
Думал, что такой подход неоптимален и неудобен, пока на двух последних проектах не использовал эту практику. Выделенный человек писал и оптимизировал запросы и структуру базы. Разработчики приложения также писали SQL код, но всё уходило на ревью. В итоге с производительностью на базе никогда проблем не было, код качественный, чистый и аккуратный.
Из минусов:
— много одинакового кода (но из-за особенностей sql server'а не всё можно вынести в общие процедуры/функции/вью)
— при большом количестве разработчиков датабазник становится бутылочным горлышком
Для сравнения заглянул в репозиторий проекта, где все писали SQL код и иногда использовали Linq To Sql. Казалось бы каждый нормальный бэкенд разработчик должен на уровне понимать и писать SQL, но как оказалось, реальность далека от идеала.
Думал, что такой подход неоптимален и неудобен, пока на двух последних проектах не использовал эту практику. Выделенный человек писал и оптимизировал запросы и структуру базы. Разработчики приложения также писали SQL код, но всё уходило на ревью. В итоге с производительностью на базе никогда проблем не было, код качественный, чистый и аккуратный.
Из минусов:
— много одинакового кода (но из-за особенностей sql server'а не всё можно вынести в общие процедуры/функции/вью)
— при большом количестве разработчиков датабазник становится бутылочным горлышком
Для сравнения заглянул в репозиторий проекта, где все писали SQL код и иногда использовали Linq To Sql. Казалось бы каждый нормальный бэкенд разработчик должен на уровне понимать и писать SQL, но как оказалось, реальность далека от идеала.
То есть мифы №№5 и 6 — не мифы.
Про Миф №2 есть возражения:
Будет ввиде
И такой запрос не обрабатывается индексом.
Where(x=>x.IsActive == false) Будет ввиде
Where not (IsActive = 1)И такой запрос не обрабатывается индексом.
Sign up to leave a comment.
7 мифов о Linq to Database