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

Y>>Замеры "у нас тут голый sql" vs "ORM c прикрученым change tracking" а потом получают "шокирующие цифры" говорят скорее о квалификации тестирующих, а вовсе не о том, что тестируется.
_>Ну это не ко мне претензии, т.к. тесты делал не я и даже ссылку на них притащил не я.

Ок, переформулирую: люди, радостно кричащие "цифры шокирующие, теперь будет куда тыкать носом всяких умников" на замеры "у нас тут голый sql" vs "ORM c прикрученым change tracking" говорят скорее о квалификации кричащих, а вовсе не о том, что тестируется.

_>Но замечу, что даже если говорить только о linq2db, то оверхед в 10-50% (в зависимости от тяжести запроса) всё равно является очень существенным.

Нет, не является, потому что есть масса реальных сценариев, где всё будет наоборот.

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

_>>Но замечу, что даже если говорить только о linq2db, то оверхед в 10-50% (в зависимости от тяжести запроса) всё равно является очень существенным.
Y>Нет, не является, потому что есть масса реальных сценариев, где всё будет наоборот.

"Наоборот" — это в данном случае как? )

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

_>>>Но замечу, что даже если говорить только о linq2db, то оверхед в 10-50% (в зависимости от тяжести запроса) всё равно является очень существенным.
Y>>Нет, не является, потому что есть масса реальных сценариев, где всё будет наоборот.

_>"Наоборот" — это в данном случае как? )

Вы спрашиваете "что такое наоборот в случае, когда один опередил другого"? Это какой-то тупой тролинг, да?

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

_>>>>Но замечу, что даже если говорить только о linq2db, то оверхед в 10-50% (в зависимости от тяжести запроса) всё равно является очень существенным.
Y>>>Нет, не является, потому что есть масса реальных сценариев, где всё будет наоборот.
_>>"Наоборот" — это в данном случае как? )
Y>Вы спрашиваете "что такое наоборот в случае, когда один опередил другого"? Это какой-то тупой тролинг, да?

Я правильно понял, что ты допускаешь ситуации, в которых linq решение обойдёт по скорости запрос на голых sql строках? ))) И даже не просто допускаешь, а говоришь что "есть масса реальных сценариев"? )

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

[Skip]

_>Оптимизацию можно сделать автоматическую, ещё на стадии разработки — не использовать linq. ))) Ну во всяком случае при работе на C#, в котором недоступны средства для работы с типизированным sql без
существенного оверхеда.

Не писал ты высоконагруженные системы ой не писал.
Все в конце концов упирается в SQL Server который надо разгрузить. App серверов можна наставить хоть 100 а вот SQL Server максимум 4.
Это кеши, это правильно построенные запросы, это лоад балансер на App Server.

То что ты тут на пытаешься соптимизировать, просто пчих.

Тебе еще раз повторяю, раз ты других не слушаешь

1. Linq позволяет быстро и качественно построить запрос — тут мне насрать на оверхед рефлексии, потому что SQL Server не резиновый и главное правильный и быстрый SQL
   
2. Linq позволяет мне сделать Query Decomposition — тут я сэкономлю дни работы и недели на maintenance. В твоем же варианте ты пишешь суперпупер быстрый кусок кода, прибитый гвоздями к компиляции. Я же могу взять сторед процедуру, переписать ее на Linq и если она табличная то джоинится на нее. И на выхлопе получаю SQL под нужную мне выборку, с оптимизированными JOIN, с правильным projection и, если надо, pagination.

К примеру, писал окно поиска сущностей, с тучей всевозможных фильтров. Сущности также показывают данные из других таблиц (LEFT JOIN). Так вот, если появлялся определенный фильтр тут уже LEFT JOIN необходимо было превратить в INNER JOIN и фильтрануть по полю(ям) с этой таблицей, и если поле(я) участвует в фильтре, то и отсортировать по нему. С Linq2db это делается в пол пинка. Я просто в ужасе был бы в поддержке сего, если б склеивал строки или боролся с супер быстрым фреймворком, строящим SQL во время компиляции. К слову сказать таблицы сейчас меняются каждый день — привет, maintenance уже тут.

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

D>Не писал ты высоконагруженные системы ой не писал. Все в конце концов упирается в SQL Server который надо разгрузить.

Да, частенько упирается в БД, только это уж точно будет не SQL Server — нечего ему делать в таких системах. )))

D>App серверов можна наставить хоть 100

Ну да конечно, они же бесплатные сейчас... )))

D>а вот SQL Server максимум 4.

И за это ещё платят деньги...

D>То что ты тут на пытаешься соптимизировать, просто пчих.

И ты конечно же можешь предоставить результаты замеров, подтверждающих это? )

D>К примеру, писал окно поиска сущностей, с тучей всевозможных фильтров. Сущности также показывают данные из других таблиц (LEFT JOIN). Так вот, если появлялся определенный фильтр тут уже LEFT JOIN необходимо было превратить в INNER JOIN и фильтрануть по полю(ям) с этой таблицей, и если поле(я) участвует в фильтре, то и отсортировать по нему. С Linq2db это делается в пол пинка. Я просто в ужасе был бы в поддержке сего, если б склеивал строки или боролся с супер быстрым фреймворком, строящим SQL во время компиляции. К слову сказать таблицы сейчас меняются каждый день — привет, maintenance уже тут.

Ты хочешь сказать, что при использование linq тебе не потребуется менять своё приложение в случае изменения структуры БД? ) Будет очень любопытно взглянуть на детали реализации подобной магии... ))

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

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

D>>Не писал ты высоконагруженные системы ой не писал. Все в конце концов упирается в SQL Server который надо разгрузить.

_>Да, частенько упирается в БД, только это уж точно будет не SQL Server — нечего ему делать в таких системах. )))

Не утрируй, SQL Server для примера.

D>>App серверов можна наставить хоть 100

_>Ну да конечно, они же бесплатные сейчас... )))

Не путай понятия. App сервера доставлять можна, SQL сервер — нет.

D>>а вот SQL Server максимум 4.

_>И за это ещё платят деньги...

На чем сидим?

D>>То что ты тут на пытаешься соптимизировать, просто пчих.

_>И ты конечно же можешь предоставить результаты замеров, подтверждающих это? )

Может ты будешь спорить что правильно сгенеренный SQL для определенного случая, медленней захардкодженого, обернутого еще в один SELECT? Или с другой стороны, сколько тебе придется потратить времени чтобы создать более универсальный механизм?

D>>К примеру, писал окно поиска сущностей, с тучей всевозможных фильтров. Сущности также показывают данные из других таблиц (LEFT JOIN). Так вот, если появлялся определенный фильтр тут уже LEFT JOIN необходимо было превратить в INNER JOIN и фильтрануть по полю(ям) с этой таблицей, и если поле(я) участвует в фильтре, то и отсортировать по нему. С Linq2db это делается в пол пинка. Я просто в ужасе был бы в поддержке сего, если б склеивал строки или боролся с супер быстрым фреймворком, строящим SQL во время компиляции. К слову сказать таблицы сейчас меняются каждый день — привет, maintenance уже тут.

_>Ты хочешь сказать, что при использование linq тебе не потребуется менять своё приложение в случае изменения структуры БД? ) Будет очень любопытно взглянуть на детали реализации подобной магии... ))

Я хочу тебе сказать что это происходит безболезненно и с минимумом эфортов.

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

D>>>App серверов можна наставить хоть 100
_>>Ну да конечно, они же бесплатные сейчас... )))
D>Не путай понятия. App сервера доставлять можна, SQL сервер — нет.

Доставлять то конечно можно, если они окупаются... Понимаешь, при неограниченном финансирование я тебе сделаю шустрый высоконагруженный сервис даже на каком-нибудь древнем Basic'е. ))) Просто закажу дата-центр как у гугла (правда выполнять задачи он будет совсем не как у гугла). ))) И это всё даже будет работать, пока не обанкротится...

D>>>То что ты тут на пытаешься соптимизировать, просто пчих.
_>>И ты конечно же можешь предоставить результаты замеров, подтверждающих это? )
D>Может ты будешь спорить что правильно сгенеренный SQL для определенного случая, медленней захардкодженого, обернутого еще в один SELECT? Или с другой стороны, сколько тебе придется потратить времени чтобы создать более универсальный механизм?

Не понял эту твою фразу.

_>>Ты хочешь сказать, что при использование linq тебе не потребуется менять своё приложение в случае изменения структуры БД? ) Будет очень любопытно взглянуть на детали реализации подобной магии... ))
D>Я хочу тебе сказать что это происходит безболезненно и с минимумом эфортов.

А в чём по твоему будет болезненность в случае ORM, генерирующего sql на стадии компиляции? )

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

_>А в чём по твоему будет болезненность в случае ORM, генерирующего sql на стадии компиляции? )
На стадии компиляции точно не выйдет, по крайней мере для некоторых запросов. В зависимости от входных данных могут меняться многие части запроса, в т.ч. джойны таблиц и т.п, вложенность запросов и т.п.

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

_>>А в чём по твоему будет болезненность в случае ORM, генерирующего sql на стадии компиляции? )
dot>На стадии компиляции точно не выйдет, по крайней мере для некоторых запросов. В зависимости от входных данных могут меняться многие части запроса, в т.ч. джойны таблиц и т.п, вложенность запросов и т.п.

Различных комбинаций обычно не много, и все их можно сгенерировать заранее.

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

_>>>А в чём по твоему будет болезненность в случае ORM, генерирующего sql на стадии компиляции? )
dot>>На стадии компиляции точно не выйдет, по крайней мере для некоторых запросов. В зависимости от входных данных могут меняться многие части запроса, в т.ч. джойны таблиц и т.п, вложенность запросов и т.п.
EP>Различных комбинаций обычно не много, и все их можно сгенерировать заранее.
Количество комбинаций растёт экспоненциально. Для простенькой формы поиска с 5 опциональными критериями это уже 32 варианта.
А ещё типичный приём — построение where-условия "someColumn IN(?, ?, ..., ?)" для списка из нескольких (скажем не более 100) элементов. А представь есть три таких колонки — получается 1000000 вариантов.
Главное мне непонятно — а будет ли вообще хоть как-то заметная экономия? По сравнению непосредственно с выполнением самого запроса — конкатенация нескольких строчек и даже десяток рефлексивных вызовов составят доли процента.

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

EP>>Различных комбинаций обычно не много, и все их можно сгенерировать заранее.
dot>Количество комбинаций растёт экспоненциально.

Естественно, но при этом количество параметров обычно малое

dot>Для простенькой формы поиска с 5 опциональными критериями это уже 32 варианта.

Опциональные параметры обычно коммутативны, так что вариантов меньше. Тем не менее, даже 32 варианта не проблема — они же автоматом генерируются

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

_>>А в чём по твоему будет болезненность в случае ORM, генерирующего sql на стадии компиляции? )
·>На стадии компиляции точно не выйдет, по крайней мере для некоторых запросов. В зависимости от входных данных могут меняться многие части запроса, в т.ч. джойны таблиц и т.п, вложенность запросов и т.п.

Ну естественно речь не про то, что в exe становятся зашиты sql строки (такое собственно и не возможно, т.к. в них в любом случае будут включаться данные пользователей). Подразумевается некий код склейки каких-то готовых строк, параметров и т.п.

Ну т.е. вот смотри, допустим мы пишем работу с БД на чистом sql, вообще без всяких дополнительных инструментов. Это же реально, правильно? ) Так вот подобную реализацию можно условно считать референсной, т.к. в нет вообще никакого оверхеда.

Далее, предположим, что нам не нравится писать на чистом sql и мы хотим каких-то удобств как минимум проверку синтаксиса sql на этапе разработке и автоматическую подстройку под конкретную разновидность СУБД, а как максимум вообще какой-то удобный ORM. Но при этом хотим, что бы в итоге образовывался точной такой же код, как и в случае ручного кодирования. Это не такая простая задачка конечно, но вполне решаемая. И уже даже есть готовые варианты, в таких языках как C++, Rust и т.п.

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

EP>>>Различных комбинаций обычно не много, и все их можно сгенерировать заранее.
dot>>Количество комбинаций растёт экспоненциально.
EP>Естественно, но при этом количество параметров обычно малое
Для обычных ситуаций и проблем не будет. Хоть тупо вставь запрос как текст.

И почему ты проигнорировал в моём сообщении "IN" с миллионами комбинаций?

dot>>Для простенькой формы поиска с 5 опциональными критериями это уже 32 варианта.
EP>Опциональные параметры обычно коммутативны, так что вариантов меньше. Тем не менее, даже 32 варианта не проблема — они же автоматом генерируются
32 это для тривиальной формы с пятью критериями. Для формы с десятком параметров, плюс пару условий на фильтрование прав доступа, плюс пару условий на user preferences и внезапно — тысячи-миллионы комбинаций.

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

_>Ну естественно речь не про то, что в exe становятся зашиты sql строки (такое собственно и не возможно, т.к. в них в любом случае будут включаться данные пользователей). Подразумевается некий код склейки каких-то готовых строк, параметров и т.п.
Так параметры же разные, в зависимости от того, что пользователь навводил.

_>Ну т.е. вот смотри, допустим мы пишем работу с БД на чистом sql, вообще без всяких дополнительных инструментов. Это же реально, правильно? ) Так вот подобную реализацию можно условно считать референсной, т.к. в нет вообще никакого оверхеда.
Реально в тривиальных случаях.

_>Далее, предположим, что нам не нравится писать на чистом sql и мы хотим каких-то удобств как минимум проверку синтаксиса sql на этапе разработке и автоматическую подстройку под конкретную разновидность СУБД, а как максимум вообще какой-то удобный ORM. Но при этом хотим, что бы в итоге образовывался точной такой же код, как и в случае ручного кодирования. Это не такая простая задачка конечно, но вполне решаемая. И уже даже есть готовые варианты, в таких языках как C++, Rust и т.п.
И сколько процентов времени исполнения удастся сэкономить? Хватит теоретизировать, конкретные замеры в студию.

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

dot>И почему ты проигнорировал в моём сообщении "IN" с миллионами комбинаций?

Динамичные части запроса не противоречат идея обхода деревьев выражения во время компиляции, хотя бы частично, плюс остаётся генерация готовых отдельных кусков, которые будут склеивается в runtime

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

_>>Ну т.е. вот смотри, допустим мы пишем работу с БД на чистом sql, вообще без всяких дополнительных инструментов. Это же реально, правильно? ) Так вот подобную реализацию можно условно считать референсной, т.к. в нет вообще никакого оверхеда.
·>Реально в тривиальных случаях.

В каких ещё тривиальных случаях? ) Раньше вообще только так весь код писали и всё. )))

_>>Далее, предположим, что нам не нравится писать на чистом sql и мы хотим каких-то удобств как минимум проверку синтаксиса sql на этапе разработке и автоматическую подстройку под конкретную разновидность СУБД, а как максимум вообще какой-то удобный ORM. Но при этом хотим, что бы в итоге образовывался точной такой же код, как и в случае ручного кодирования. Это не такая простая задачка конечно, но вполне решаемая. И уже даже есть готовые варианты, в таких языках как C++, Rust и т.п.
·>И сколько процентов времени исполнения удастся сэкономить? Хватит теоретизировать, конкретные замеры в студию.

Сэкономить? ) В каком смысле? Относительно склейки строк такая система не даёт никакой экономии. Она привносит удобство и безопасность.

В этой же темке обсуждался другой вопрос. Что в .net попытались создать некое подобное такой системы на базе задание запросов в виде linq выражений и разбора их потом в рантайме. Удобство и безопасность они при этом реализовать сумели, но только ценой большого оверхеда (т.е. кроме указанной выше склейки строк и параметров в рантайме делается ещё куча всего ненужного, типа обходов деревьев linq выражений через рефлексию и т.п.). Оценки этого оверхеда (те самые реальные замеры, которые ты хотел) можно увидеть в сообщения выше — там местами до 500% доходит. )))

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

dot>>И почему ты проигнорировал в моём сообщении "IN" с миллионами комбинаций?
EP>Динамичные части запроса не противоречат идея обхода деревьев выражения во время компиляции, хотя бы частично, плюс остаётся генерация готовых отдельных кусков, которые будут склеивается в runtime
Допустим. Что это даст, кроме излишней сложности? Если скорость, то цифры в студию.

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

_>>>Ну т.е. вот смотри, допустим мы пишем работу с БД на чистом sql, вообще без всяких дополнительных инструментов. Это же реально, правильно? ) Так вот подобную реализацию можно условно считать референсной, т.к. в нет вообще никакого оверхеда.
_>·>Реально в тривиальных случаях.
_>В каких ещё тривиальных случаях? ) Раньше вообще только так весь код писали и всё. )))
Так раньше код на перфокартах писали... и что?

_>>>Далее, предположим, что нам не нравится писать на чистом sql и мы хотим каких-то удобств как минимум проверку синтаксиса sql на этапе разработке и автоматическую подстройку под конкретную разновидность СУБД, а как максимум вообще какой-то удобный ORM. Но при этом хотим, что бы в итоге образовывался точной такой же код, как и в случае ручного кодирования. Это не такая простая задачка конечно, но вполне решаемая. И уже даже есть готовые варианты, в таких языках как C++, Rust и т.п.
_>·>И сколько процентов времени исполнения удастся сэкономить? Хватит теоретизировать, конкретные замеры в студию.
_>Сэкономить? ) В каком смысле? Относительно склейки строк такая система не даёт никакой экономии. Она привносит удобство и безопасность.

_>В этой же темке обсуждался другой вопрос. Что в .net попытались создать некое подобное такой системы на базе задание запросов в виде linq выражений и разбора их потом в рантайме. Удобство и безопасность они при этом реализовать сумели, но только ценой большого оверхеда (т.е. кроме указанной выше склейки строк и параметров в рантайме делается ещё куча всего ненужного, типа обходов деревьев linq выражений через рефлексию и т.п.). Оценки этого оверхеда (те самые реальные замеры, которые ты хотел) можно увидеть в сообщения выше — там местами до 500% доходит. )))
Там замеры были или корявые (ну кто меряет тест выполнения запросов, выполняя инструкцию 1 раз и сравнивая 10мс и 13мс?! и делая вывод — 146%!). Либо тормоза возникали из-за других фич. Измерение конкретно рефлексии или склейки строк не было. Или я что-то пропустил?

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

dot>Допустим. Что это даст, кроме излишней сложности? Если скорость, то цифры в студию.

Это даст скорость априори, так как не будет лишней работы в runtime.
Сколько — другой вопрос, если интересно, то можешь сам легко сравнить, для этого мета-систему необязательно писать — сравни полностью ручной-оптимальный вариант против передовых LINQ решений
Я же отвечал конкретно на тезис о невозможности.