Здравствуйте, gandjustas, Вы писали:
G>Ну и самый главный косяк. У тебя по сути нет комбинирования запросов. Если добавить в Cutomer поле, то его надо будет прописать во все релевантные запросы. Для linq надо будет поправить функцию, накладывающую проекцию на запрос.
Комбинирование запросов было в SQL испокон веков. А склейка строк позволяет реюзать код, т.е. текст.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Здравствуйте, gandjustas, Вы писали:
G>>1) чем это компилировать? AP>Приведенный код компилируется обычным C# компилятором. Для проверки запросов надо дернуть метод CheckAllQueries AP>
G>>2) где гарантия что GoldCutomer надо вызвать для списка кастомеров? AP>Метод GoldCutomer просто подставляет кусок текста. Проверяется лишь, что итоговый запрос валидный. Т.е. если "с" будет иметь нужные колонки, то проверка пройдет.
Ну вот, кусок текста... получается что тот кто вызывает функцию goldCustomer должен знать что она возвращает и специальным образом адаптировать исходный запрос. Такому подходу до удобства linq как дол Китая.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>... развитые средства декомпозиции дают вполне неиллюзорные бенефиты.
Подожди, о каких "развитых" средствах декомпозиции идет речь?
Вот если у меня IEnumerable<T>, то, да, декомпозиция, действительно развитая, это факт. Например,
IEnumerable<int> ints = ...;
ints.Where(x => MyMethod(x, c1, c2) || (x > c3 && x < c4));
private static bool MyMethod(int x, int c1, int c2)
{
return (x > c1 && x < c2);
}
Буквально, выделяю фрагмент кода, и ReSharper мне делает декомпозицию. Красота!
А если у нас IQueryable<T>? Упс, уже совсем не так всё радужно. Как мне кусок кода выделить в отдельную единицу -- метод MyMethod?
Для IQueryable<T> у нас остаются довольно убогие средства декомпозиции.
1. Подать экспрешен на в ход в другой экспрешен.
2. В логических выражениях "вырезать" подвыражение, объединяя его с какой-нибудь внешней переменной через оператор &&, полагаясь на оптимизатор linq провайдера.
Разве еще что-то есть для декомпозиции?
Сам Anders Hejlsberg для динамических запросов предлагает склейку строк. О каких развитых средствах декомпозиции вы толкуете, не дизайнился LINQ для динамических запросов к БД.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>А если у нас IQueryable<T>? Упс, уже совсем не так всё радужно. Как мне кусок кода выделить в отдельную единицу -- метод MyMethod?
Очень странный вопрос. В чем проблема?
AP>Для IQueryable<T> у нас остаются довольно убогие средства декомпозиции. AP>1. Подать экспрешен на в ход в другой экспрешен.
Здравствуйте, gandjustas, Вы писали:
G>Выложи куданить проект.
Собираюсь выложить на github.
G>Ну вот, кусок текста... получается что тот кто вызывает функцию goldCustomer должен знать что она возвращает и специальным образом адаптировать исходный запрос. Такому подходу до удобства linq как дол Китая.
Во-первых, ничего адаптировать не надо, это ты бредишь.
А если поразмышлять, то сколько-нибудь значимой проблемы либо нет, либо это даже бонус. Вот в TypeScript переменная имеет тип интерфейс, и этой переменной можно присваивать объекты, которые и не знают об этом интерфейсе. Только само присвоение вызывает проверку. А в моем примере пошли еще чуть дальше, и интерфейс объявлять не надо, интерфейс определяется из использования столбцов. Я бы и в C# от такого не отказался, но, наверное, это сильно дорого делать такое на больших объемах кода, поэтому и прописывают декларации в явном виде.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Очень странный вопрос. В чем проблема?
Приведи свой вариант кода для IQueryable того, что я сделал для IEnumerable. Выдели метод MyMethod.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Здравствуйте, gandjustas, Вы писали:
G>>Выложи куданить проект. AP>Собираюсь выложить на github.
G>>Ну вот, кусок текста... получается что тот кто вызывает функцию goldCustomer должен знать что она возвращает и специальным образом адаптировать исходный запрос. Такому подходу до удобства linq как дол Китая. AP>Во-первых, ничего адаптировать не надо, это ты бредишь. AP>А если поразмышлять, то сколько-нибудь значимой проблемы либо нет, либо это даже бонус. Вот в TypeScript переменная имеет тип интерфейс, и этой переменной можно присваивать объекты, которые и не знают об этом интерфейсе. Только само присвоение вызывает проверку. А в моем примере пошли еще чуть дальше, и интерфейс объявлять не надо, интерфейс определяется из использования столбцов. Я бы и в C# от такого не отказался, но, наверное, это сильно дорого делать такое на больших объемах кода, поэтому и прописывают декларации в явном виде.
Самое главное find usages и рефакторинг работают, а остальное всё словоблудие.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Здравствуйте, gandjustas, Вы писали:
G>>Выложи куданить проект. AP>Собираюсь выложить на github.
G>>Ну вот, кусок текста... получается что тот кто вызывает функцию goldCustomer должен знать что она возвращает и специальным образом адаптировать исходный запрос. Такому подходу до удобства linq как дол Китая. AP>Во-первых, ничего адаптировать не надо, это ты бредишь.
во-первых бредишь ты, во вторых в запросе к Customers обязательно надо прописать алиас «c», причем из скомпилированной сборки ты этого не узнаешь, в третьих GoldCustomer не будет проверяться без основного запроса, ибо даже не является корректным sql.
AP>А если поразмышлять, то сколько-нибудь значимой проблемы либо нет, либо это даже бонус.
Можно и поразмышлять, но проблемы никуда не денутся. Затраты на написание, бакфикс и поддержку с идеологией никак не связаны, как бы не казалось обратное.
AP> Вот в TypeScript переменная имеет тип интерфейс, и этой переменной можно присваивать объекты, которые и не знают об этом интерфейсе. Только само присвоение вызывает проверку. А в моем примере пошли еще чуть дальше, и интерфейс объявлять не надо, интерфейс определяется из использования столбцов. Я бы и в C# от такого не отказался, но, наверное, это сильно дорого делать такое на больших объемах кода, поэтому и прописывают декларации в явном виде.
Как коррелирует то что ты написал со склейкой строк?
Здравствуйте, Alexander Polyakov, Вы писали:
AP>А если у нас IQueryable<T>? Упс, уже совсем не так всё радужно. Как мне кусок кода выделить в отдельную единицу -- метод MyMethod?
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Здравствуйте, gandjustas, Вы писали:
G>>Ну и самый главный косяк. У тебя по сути нет комбинирования запросов. Если добавить в Cutomer поле, то его надо будет прописать во все релевантные запросы. Для linq надо будет поправить функцию, накладывающую проекцию на запрос. AP>Комбинирование запросов было в SQL испокон веков. А склейка строк позволяет реюзать код, т.е. текст.
Да ну? Подскажи как в sql взять запрос (как объект) и применить к нему функцию, добавляющую например предикат к запросу и возвращающую новый «объект» запроса. Аналог where в Linq.
Любой кто познал выгоду между параметризированными запросами и перед запросами с константами — тот поймет и всю силу статистики и прочу ересь которая в кверике выполняется моментально — а в приложении — нет.
Так вот — я к чему — LINQ — это как раз инструмент, который, особенно если очень захотеть, заставит исполнять запросы с параметризаций as-is. А это значит и с применением статистики. Это именно то чего не дают процедуры (хотя процедуры дают своё в другом) — тем не менее — если взять в среднем по палате — ну у меня не получается сиквел загрузить. А вот загрузить его тупыми запросами которые скомпилированы (в случае проц) под общий случай — этого говна было навалом. Безусловно WITH RECOMPILE помогает везде и всем — только как только защитники SP спускаются к WITH RECOMPILE — это значит что те кто юзают LINQ — имеют такое же право. А это всё в своё очередь означает следующее:
1) Сиквел ахриненно вычисляет совсем уж похожие запросы и так (даже с другими параметрами), хотя это — критиковать можно
2) Поборники хранимок — очнитесь — мир давно перевернулся, и реально запросы легче писать тем же LINQ. Более того — они имеют шанс выполняться более эффективно.
Насчет второго — я расскажу так. Запрос в хранимке компилируется обычно и хана. Пока никто не наступит на то, что его параметры совсем не подходят к их плану — WITH RECOMPILE — процу не метит. Только прежде чем обнаружить такую проблему — ну это скажем так часов 2-8 простоя весьма немалых организаций. Поэтому рассказывать о том что там надо или не надо следить — не нужно тут мне. Следить надо. По факту — специалистов которые знают за чем *можно* следить — нет.
Как тут выигрывает LINQ? Если есть нетривиальные запросы — он просто будет константно выигрывать, против старого доброго процедурного подхода. Будет сиквет перекомпилировать запрос всегда? Да. Ну почти да.
Будет ли это быстрее? Ну скорее всего да. Самое главное не в этом — при появлении входных данных которые выбиваются из общей канвы — всё по прежнему будет работать.
Ну а знатоки проц — знают — без WITH RECOMPILE — это не победимо — кто первый дернул её со своими параметрами — того и план. А эффективен он или нет — сиквелу как бы пофигу.
PS: Я знаю, что тема немного о другом — но и об этом тоже. Выгоднее ли исполнять хранимки — конечно да. Выгоднее ли всегда — далеко не факт. Можно ли забить на этот анархизм? Конечно нет! Но LINQ в любом своём проявлении особенно с linq2db — точно показывает себя более чем достойно.
Да. Поборники достойности — мой десктоп способен обслужить 7K+ запросов весьма нифика не простых запросов. И это всё через LINQ. RAW — будет быстрее. Но — ещё быстрее — будет без SQL вообще. Так что заранее прошу — глупости тут не городить. Да. Без сиквела — 20K+.
Здравствуйте, gandjustas, Вы писали:
AP>>А если у нас IQueryable<T>? Упс, уже совсем не так всё радужно. Как мне ку7сок кода выделить в отдельную единицу -- метод MyMethod? G>Да легко http://gandjustas.blogspot.ru/2010/06/expression-tree.html7
Отлично, те "развитые" средства декомпозиции, которые преподносятся как основное killer application для linq к БД, оказывается изложены в русскоязычном блоге некоего gandjustas. Это еще раз подтверждает, что разработчики linq не дизайнели его для динамических запросов к БД.
То такой код даже не скомпилируется, потому что e1.Entity2 не реализует интерфейс IQueryable<T>. Даже если бы такой ко компилировался, то наверняка отвалился бы в runtume, потому что Linq провайдер не знает что делать с методом Visible.
...
Но какой тип должен быть у предиката Visible? ...
Т.е. боремся с этими несчастными экспрешенами, вместо того, чтобы писать запрос, который реализует бизнес-логику (реализацию, которой нам и оплачивает заказчик). Голова программиста занята борьбой с экспрешенами, типами и т.д., вместо того, чтобы заниматься прямыми обязанностями по реализации бизнес-логики.
Слишком дорого. За что мы платим такую цену? За проверку ошибок на этапе компиляции, find usages и рефакторинг. Но есть вариант всё это получить гораздо дешевле.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
F>Ребята, я всем очень благодарен за участие.
F>Но спорите не о том.
F>Любой кто познал выгоду между параметризированными запросами и перед запросами с константами — тот поймет и всю силу статистики и прочу ересь которая в кверике выполняется моментально — а в приложении — нет.
F>Так вот — я к чему — LINQ — это как раз инструмент, который, особенно если очень захотеть, заставит исполнять запросы с параметризаций as-is. А это значит и с применением статистики. Это именно то чего не дают процедуры (хотя процедуры дают своё в другом) — тем не менее — если взять в среднем по палате — ну у меня не получается сиквел загрузить. А вот загрузить его тупыми запросами которые скомпилированы (в случае проц) под общий случай — этого говна было навалом. Безусловно WITH RECOMPILE помогает везде и всем — только как только защитники SP спускаются к WITH RECOMPILE — это значит что те кто юзают LINQ — имеют такое же право. А это всё в своё очередь означает следующее: F> 1) Сиквел ахриненно вычисляет совсем уж похожие запросы и так (даже с другими параметрами), хотя это — критиковать можно F> 2) Поборники хранимок — очнитесь — мир давно перевернулся, и реально запросы легче писать тем же LINQ. Более того — они имеют шанс выполняться более эффективно.
F> Насчет второго — я расскажу так. Запрос в хранимке компилируется обычно и хана. Пока никто не наступит на то, что его параметры совсем не подходят к их плану — WITH RECOMPILE — процу не метит. Только прежде чем обнаружить такую проблему — ну это скажем так часов 2-8 простоя весьма немалых организаций. Поэтому рассказывать о том что там надо или не надо следить — не нужно тут мне. Следить надо. По факту — специалистов которые знают за чем *можно* следить — нет. F> Как тут выигрывает LINQ? Если есть нетривиальные запросы — он просто будет константно выигрывать, против старого доброго процедурного подхода. Будет сиквет перекомпилировать запрос всегда? Да. Ну почти да. F> Будет ли это быстрее? Ну скорее всего да. Самое главное не в этом — при появлении входных данных которые выбиваются из общей канвы — всё по прежнему будет работать. F> Ну а знатоки проц — знают — без WITH RECOMPILE — это не победимо — кто первый дернул её со своими параметрами — того и план. А эффективен он или нет — сиквелу как бы пофигу.
F> PS: Я знаю, что тема немного о другом — но и об этом тоже. Выгоднее ли исполнять хранимки — конечно да. Выгоднее ли всегда — далеко не факт. Можно ли забить на этот анархизм? Конечно нет! Но LINQ в любом своём проявлении особенно с linq2db — точно показывает себя более чем достойно. F> Да. Поборники достойности — мой десктоп способен обслужить 7K+ запросов весьма нифика не простых запросов. И это всё через LINQ. RAW — будет быстрее. Но — ещё быстрее — будет без SQL вообще. Так что заранее прошу — глупости тут не городить. Да. Без сиквела — 20K+.
В этой ветке никто не спорит о нужности динамических запросов. Обсуждаются способы их реализации.
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Здравствуйте, gandjustas, Вы писали: AP>Т.е. боремся с этими несчастными экспрешенами, вместо того, чтобы писать запрос, который реализует бизнес-логику (реализацию, которой нам и оплачивает заказчик). Голова программиста занята борьбой с экспрешенами, типами и т.д., вместо того, чтобы заниматься прямыми обязанностями по реализации бизнес-логики. AP>Слишком дорого. За что мы платим такую цену? За проверку ошибок на этапе компиляции, find usages и рефакторинг. Но есть вариант всё это получить гораздо дешевле.
Еще раз повторю, идеология и затраты на разработку и поддержку не связаны. По факту linq знают 90% программистов на c#, а sql, хотя бы на уровне написания джоинов, от силы 50%. Linq позволяет делать меньше ошибок при написании и экономит на поддержке за счет декомпозиции. Так что в среднем linq эффектинее на порядок, то есть получает тот же результат при гораздо меньших затратах. А такие вещи, как миграции в ef, экономят время настолько, что перекрывают любые преимущества, которые могут быть у текстовых запросов.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, gandjustas, Вы писали:
F>Ребята, я всем очень благодарен за участие.
F>Но спорите не о том.
F> ... поскипано...
Не очень понял зачем ты мне это написал.
F> Как тут выигрывает LINQ? Если есть нетривиальные запросы — он просто будет константно выигрывать, против старого доброго процедурного подхода. Будет сиквет перекомпилировать запрос всегда? Да. Ну почти да.
Нет, потому что SqlCommand, используемый Linq2SQL, EF и всеми остальными orm, вызывает sp_executesql, который форсирует параметризацию. Это хорошо, когда есть покрывающий индекс с высокой селективность, и ужасно когда такового нет, потому что закеширует план с index\table scan, и начнет тормозить когда количество данных вырастет.
Кстати основная причина использования хранимок для выборок — возможность написать руками with(nolock), чтобы при больших выборках не лочить таблицы.
Здравствуйте, fddima, Вы писали:
F> Насчет второго — я расскажу так. Запрос в хранимке компилируется обычно и хана. Пока никто не наступит на то, что его параметры совсем не подходят к их плану — WITH RECOMPILE — процу не метит. Только прежде чем обнаружить такую проблему — ну это скажем так часов 2-8 простоя весьма немалых организаций. Поэтому рассказывать о том что там надо или не надо следить — не нужно тут мне. Следить надо. По факту — специалистов которые знают за чем *можно* следить — нет.
Эмм???
Я сейчас могу гнать, по памяти, как минимум в ms sql 2008r2 execution plan кэшируется одинаково и для хранимок, и для параметризованных sql-забросов — после вылета из кэша происходит рекомпиляция. Например, вот подтверждение (см "Reasons Stored Procedures Recompile")
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, fddima, Вы писали:
F>> Насчет второго — я расскажу так. Запрос в хранимке компилируется обычно и хана. Пока никто не наступит на то, что его параметры совсем не подходят к их плану — WITH RECOMPILE — процу не метит. Только прежде чем обнаружить такую проблему — ну это скажем так часов 2-8 простоя весьма немалых организаций. Поэтому рассказывать о том что там надо или не надо следить — не нужно тут мне. Следить надо. По факту — специалистов которые знают за чем *можно* следить — нет.
S>Эмм???
S>Я сейчас могу гнать, по памяти, как минимум в ms sql 2008r2 execution plan кэшируется одинаково и для хранимок, и для параметризованных sql-забросов — после вылета из кэша происходит рекомпиляция. Например, вот подтверждение (см "Reasons Stored Procedures Recompile")
S>А вот пример похожих проблем с параметризованными запросами: S>http://stackoverflow.com/questions/13635531/optimizing-execution-plans-for-parameterized-t-sql-queries-containing-window-fun
S>Причём в кеш могут попасть и автопараметризованные запросы (для самых простых случаев), например, см секцию Auto-Parameterization в sql perf distilled
Как обычно все немного сложнее. Процедуры компилируются в момент первого вызова, причем с учетом параметров, которые передали в процедуру. План, оптимальный для этих параметров, может быть крайне неоптимальным для других. При вызове sqlcommand с параметрами запрос попадает в sp_executesql, где принудительно параметизуется. Таким образом для linq запросов создается план который работает одинаково (хорошо или плохо — зависит от кучи факторов), а для хранимок может быть закеширован план, который работает хорошо на одном значении параметра и ужасно на другом.
Здравствуйте, Alexander Polyakov, Вы писали:
НС>>Очень странный вопрос. В чем проблема? AP>Приведи свой вариант кода для IQueryable того, что я сделал для IEnumerable. Выдели метод MyMethod.
private static Expression<Func<int, bool>> MyMethod(int c1, int c2)
{
return x => x > c1 && x < c2;
}
Здравствуйте, gandjustas, Вы писали:
G>Как обычно все немного сложнее. Процедуры компилируются в момент первого вызова, причем с учетом параметров, которые передали в процедуру. План, оптимальный для этих параметров, может быть крайне неоптимальным для других. При вызове sqlcommand с параметрами запрос попадает в sp_executesql, где принудительно параметизуется. Таким образом для linq запросов создается план который работает одинаково (хорошо или плохо — зависит от кучи факторов), а для хранимок может быть закеширован план, который работает хорошо на одном значении параметра и ужасно на другом.
Так, я всё-таки торможу
Для хранимок:
план строится по первому запуску, строится по переданным аргументам, кэшируется до выпадения из кэша.
Для параметризованного sql (sp_executesql):
план строится по первому запуску, строится по переданным аргументам, кэшируется до выпадения из кэша.
* про авто-параметризацию пока забудем, считаем что в executesql пришёл запрос с явно прописанными параметрами.
В чём разница?
Выше приводил ссылку, что-то похожее наблюдал лично на ms sql 2008r2: что для хранимых процедур, что для sp_executesql мог использоваться неоптимальный план. Возможно это было просто совпадение, в документации тогда толком не копался.
Быстро поискал — вот ещё пруф.
Как мне кусок кода выделить в отдельную единицу -- метод MyMethod?
А вот загрузить его тупыми запросами которые скомпилированы (в случае проц) под общий случай — этого говна было навалом. 
