В текущей версии баг пофикшен, версия 4.3.1 была более двух лет назад, за это время можно было мигрироваться. Если вы этого не сделали, то это не проблема EF или другого провайдера.
Вообще ничего не гарантированно, что захотят авторы конкретного провайдера, то и будут делать. По сути единственное требование к провайдерам — семантика Linq запроса к базе должна быть похожа на семантику Linq запроса к объектам. Все остальное на усмотрение авторов.
1) Все известные провайдеры поддерживают DateTime, если не полностью, то частично
2) Все известные провайдеры поддерживают функции. Суть не в конкретной функции, а в том что функции не будут оптимизироваться во многих случаях.
Конкретно этот запрос не проверял, в зависимости от провайдера может разный запрос получится. Поэтому рассчитывать, что не будет скана или его можно будет убрать — нельзя.
1) Хинты в Linq не нужны. Linq не генерирует таких запросов, чтобы их пришлось пинать план хинтами. Если план запроса плохой, то надо смотреть индексы и статистику, а не писать хины. Хинты блокировок тоже не самая лучшая идея, лучше выбрать уровень изоляции правильный для твоего случая и ограничить выборку, чем писать хинты. Но если очень надо, то есть Plan Guide, который может DBA навесить на любой запрос, программисту это категорически не надо делать.
2) Изменения атомарны, SaveChanges во всех провайдерах выполняется в транзакции, все или ничего, поэтому неконсистентность базы получить нельзя.
3) Транзакции можно вручную открывать и закрывать во многих провайдерах.
4) На уровне СУБД каждый запрос компилируется. Во всех распространенных провайдерах есть свой компилятор запроса, который один раз преобразует Linq в SQL и отдает тебе фукнцию, через которую можно результаты получить. Но обычно это доли, которые могут быть важны только при очень большой нагрузке (такой, которую менее 1% увидят в жизни увидят).
Во что превратиться AddDays зависит от провайдера. EF например не поддерживает, но можно заменить на DbFunctions.AddDays, а в Linq2SQL я использовал DateTime.AddDays в запросах. В точки зрения SQL — одинаково, поэтому нет смысла писать больше.
Про проектирование все правильно написано, если предположить что все известно заранее (редко, но бывает). Но как это помешает программисту написать кривой запрос, как в посте? И самая лучшая схема не поможет запрос соптимизировать если он криво написан.
Лечить table scan добавлением памяти и процессоров — это пять. Table Scan, особенно если большая таблица, не лечится добавлением процессоров, да и добавление памяти не сильно помогает. «Магические» индексы тоже не помогают если предикат кривой. В итоге сначала все равно придется править запросы, а потом уже смотреть на схему.
Аналогии по умолчанию лживы. Например конструкторские дисциплины опираются на физику, а в разработке ПО влияние физики незаметно мало отличается от нуля. А многие другие факторы слишком субъективны и неформализуемы.
Фактически есть только 3 измеряемые величины в разработке ПО — кол-во строк кода в проекте, продуктивность (кол-во строк кода в единицу времени), и плотность дефектов (кол-во дефектов на 1000 строк). Вот это «физика» разработки ПО, все остальное субъективно. При такой «физике» строить закономерности сложно.
Там все хитрее, одна запись должна целиком влезать на страницу, то есть быть не длиннее 8000 с мелочью байт. Если у тебя несколько полей nvarchar(max) и во всех достаточно длинный текст, то они все пойду в отдельную страницу. Поэтому с короткими строками такой проблемы нет вообще, а с длинными, такими как описание товара, проблема встает в полный рост.
В идеале запрос на список чего-либо должен полностью покрываться индексом, чтобы вообще не требовалось обращаться к страницам данных. Но в индекс включать nvarchar(max) колонки — крайне плохая идея.
Поэтому в общем случае вертикальное секционирование проблему не решает.
Для примера — таблица товара имеет поле Description nvarchar(max). По умолчанию оно попадает на отдельные страницы данных в SQL Server, поэтому если не укажешь в проекции то вытягиваться не будет.
С другой стороны на странице редактирования товара ты захочешь использовать Model Binding, которому понадобится целый объект вместе с полем Description, и ты настроишь маппер так, чтобы целый объект у тебя формировался с помощью Join. Но тогда такой же целый объект будет формироваться при выводе каталога, если ты не напишешь проекцию.
Вообще пытаться оптимизировать структуру базы до того как оптимизированы запросы — контрпродуктивно.
Совсем. Linq позволяет сформировать запрос очень точно под каждый сценарий, учеть все проекции, фильтры, постраничную разбивку. Если использовать процедуры, то надо или делать кучу процедур под каждый сценарий (а потом мучительно их поддерживать), или клеить строки внутри процедур в SQL, что еще хуже, чем клеить строки руками в приложении.
Процедуры могут помочь когда возможностей Linq-провайдеров недостаточно, но заменить Linq, не потеряв темп разработки и\или быстродействие, почти нереально.
С первых версий разрешал. В Linq2SQL было ограничение, что нельзя делать проекцию на тип, на который замаплена таблица, иначе это бы ломало Change Tracking. В EF возможно есть такое же ограничение, надо проверить, хотя маловероятно.
Срабатывает очень простая логика — чем больше ты получаешь как специалист, тем меньше для работодателя причин для твоего повышения:
1) Получить плохого менеджера за большие деньги, хуже чем иметь хорошего спеца за эти же деньги.
2) Чем больше денег ты получаешь, тем меньше шанс, что уйдешь сам.
Вот ты работаешь 40 часов в неделю и работодатель тебе за это платит. Он специально нанял менеджера, который должен добиваться того, чтобы ты 40 часов тратил эффективно.
Если ты со временем стал работать больше, то один из вариантов:
1) Раньше ты реально работал не 40 часов, а меньше. Это косяк менеджера, он не получит премию.
2) Ты стал работать эффективнее, выполняя больше работы за то же время. Это значит что работодатель в тебя инвестировал, а сейчас отбивает инвестиции.
То есть у того, кто платит деньги, нет стимула задумываться о твоей ЗП. Менеджеру тоже нет особого смысла доносить идею до того, кто платит деньги по тем же причинам выше.
Другое дело если твоя ЗП не соответствует рыночной. Тогда выгоднее поднять тебе ЗП, чем искать нового человека в случае твоего ухода. Ты это можешь подтвердить офером или статистикой с HH. Об этом надо заранее сообщать менеджеру.
Если ты просто считаешь что работаешь много, то это не аргумент, а скорее проблема для менеджера.
Заголовок статьи не соответствует содержанию. На оба вопроса в заголовке ответов нет. Не ясно как обсуждать деньги и почему останавливаются карьеры.
Пост обо всем и ни о чем одновременно. Сборник наблюдений, не более того. Мне кажется к 35-40 годам у каждого такой сборник наблюдений наберется.
Я понимаю что вы продаете тренинги, но давайте хоть немного реально полезной информации в статьях. Конкретные советы и алгоритмы, а не «Общие соображения».
Не было, я руками workflow делал ровно один раз, но там не было нагрузки, чтобы это стало проблемой. С момента появления wfm использую только его. Процессы ессесно не realtime, точности достаточно в одну минуту, зато 10к всего процессов (из которых максимум 100 работают одновременно) выдерживает легко.
Я видел rehosting дизайнера, но для непрограммистов это неюзабельно. в sharepoint есть свой дизайнер, который в разы проще, и то люди с трудом им пользуются, в crm аналогично. Для sharepoint есть еще фишка — создание workflow в visio, но в визио можно сделать только форму, а логику надо все равно делать в дизайнере sharepoint.
Слишком много заблуждений в одной статье. Видно что автор с технологией не знаком.
Workflow Foundation никогда не был инструментом для аналитиков, даже дизайнера wf вне VS никогда не было. А уж удобного для людей, а не программистов, и подавно.
WF используется в нескольких продуктах microsoft, таких как sharepoint и dynamics crm. собственно первый wf появился как раз из-за sharepoint, а wf4 из-за dynamics. Начиная с версии sharepoint 2013 для WF используется отдельный сервер, который можно нужно использовать и в своих приложениях. Самое главное что во всех этих серверах используется свой workflow host, в котором нет описанных недостатков.
Короче ваша статья была бы актуальна на момент выхода .net4 в 2010 году, но уже 2014 и многое изменилось, особенно понимание как должен работать workflow, советую вам это изучить.
Самое главное — workflow хорошо работает когда много параллельно ожидающих процессов. Например есть сценарий рассылки для новых клиентов, где каждому отправляется по одному письму в неделю. Реализация такого робота в коде получается громоздкой, а в wf — элементарной.
2) Все известные провайдеры поддерживают функции. Суть не в конкретной функции, а в том что функции не будут оптимизироваться во многих случаях.
ЗЫ. Не одень, а надень.
2) Изменения атомарны, SaveChanges во всех провайдерах выполняется в транзакции, все или ничего, поэтому неконсистентность базы получить нельзя.
3) Транзакции можно вручную открывать и закрывать во многих провайдерах.
4) На уровне СУБД каждый запрос компилируется. Во всех распространенных провайдерах есть свой компилятор запроса, который один раз преобразует Linq в SQL и отдает тебе фукнцию, через которую можно результаты получить. Но обычно это доли, которые могут быть важны только при очень большой нагрузке (такой, которую менее 1% увидят в жизни увидят).
DbFunctions.AddDays, а в Linq2SQL я использовалDateTime.AddDaysв запросах. В точки зрения SQL — одинаково, поэтому нет смысла писать больше.Лечить table scan добавлением памяти и процессоров — это пять. Table Scan, особенно если большая таблица, не лечится добавлением процессоров, да и добавление памяти не сильно помогает. «Магические» индексы тоже не помогают если предикат кривой. В итоге сначала все равно придется править запросы, а потом уже смотреть на схему.
Аналогии по умолчанию лживы. Например конструкторские дисциплины опираются на физику, а в разработке ПО влияние физики незаметно мало отличается от нуля. А многие другие факторы слишком субъективны и неформализуемы.
Фактически есть только 3 измеряемые величины в разработке ПО — кол-во строк кода в проекте, продуктивность (кол-во строк кода в единицу времени), и плотность дефектов (кол-во дефектов на 1000 строк). Вот это «физика» разработки ПО, все остальное субъективно. При такой «физике» строить закономерности сложно.
В идеале запрос на список чего-либо должен полностью покрываться индексом, чтобы вообще не требовалось обращаться к страницам данных. Но в индекс включать nvarchar(max) колонки — крайне плохая идея.
Поэтому в общем случае вертикальное секционирование проблему не решает.
Для примера — таблица товара имеет поле
Description nvarchar(max). По умолчанию оно попадает на отдельные страницы данных в SQL Server, поэтому если не укажешь в проекции то вытягиваться не будет.С другой стороны на странице редактирования товара ты захочешь использовать Model Binding, которому понадобится целый объект вместе с полем Description, и ты настроишь маппер так, чтобы целый объект у тебя формировался с помощью Join. Но тогда такой же целый объект будет формироваться при выводе каталога, если ты не напишешь проекцию.
Вообще пытаться оптимизировать структуру базы до того как оптимизированы запросы — контрпродуктивно.
Процедуры могут помочь когда возможностей Linq-провайдеров недостаточно, но заменить Linq, не потеряв темп разработки и\или быстродействие, почти нереально.
1) Получить плохого менеджера за большие деньги, хуже чем иметь хорошего спеца за эти же деньги.
2) Чем больше денег ты получаешь, тем меньше шанс, что уйдешь сам.
Если ты со временем стал работать больше, то один из вариантов:
1) Раньше ты реально работал не 40 часов, а меньше. Это косяк менеджера, он не получит премию.
2) Ты стал работать эффективнее, выполняя больше работы за то же время. Это значит что работодатель в тебя инвестировал, а сейчас отбивает инвестиции.
То есть у того, кто платит деньги, нет стимула задумываться о твоей ЗП. Менеджеру тоже нет особого смысла доносить идею до того, кто платит деньги по тем же причинам выше.
Другое дело если твоя ЗП не соответствует рыночной. Тогда выгоднее поднять тебе ЗП, чем искать нового человека в случае твоего ухода. Ты это можешь подтвердить офером или статистикой с HH. Об этом надо заранее сообщать менеджеру.
Если ты просто считаешь что работаешь много, то это не аргумент, а скорее проблема для менеджера.
Пост обо всем и ни о чем одновременно. Сборник наблюдений, не более того. Мне кажется к 35-40 годам у каждого такой сборник наблюдений наберется.
Я понимаю что вы продаете тренинги, но давайте хоть немного реально полезной информации в статьях. Конкретные советы и алгоритмы, а не «Общие соображения».
Workflow Foundation никогда не был инструментом для аналитиков, даже дизайнера wf вне VS никогда не было. А уж удобного для людей, а не программистов, и подавно.
WF используется в нескольких продуктах microsoft, таких как sharepoint и dynamics crm. собственно первый wf появился как раз из-за sharepoint, а wf4 из-за dynamics. Начиная с версии sharepoint 2013 для WF используется отдельный сервер, который
можнонужно использовать и в своих приложениях. Самое главное что во всех этих серверах используется свой workflow host, в котором нет описанных недостатков.Короче ваша статья была бы актуальна на момент выхода .net4 в 2010 году, но уже 2014 и многое изменилось, особенно понимание как должен работать workflow, советую вам это изучить.
Самое главное — workflow хорошо работает когда много параллельно ожидающих процессов. Например есть сценарий рассылки для новых клиентов, где каждому отправляется по одному письму в неделю. Реализация такого робота в коде получается громоздкой, а в wf — элементарной.