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

G>2) РСУБД парсит каждый запрос (это повторяется 100500 раз) и получает в итоге один параметризованный план

G>Не проще генерировать параметризованный запрос в приложении и не тратить время на парсинг?

Он похоже сам не знает, чего же в итоге у него выходит.

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

_>Ну т.е. у нас снова беседа свелась к оценки конкретных цифр. Т.е. никто не возражает что prepare эффективнее, остаётся только вопрос на сколько.

Беседа сводится к методике измерения. У тебя она очень интересная — померять sqlite и прогретый кеш файловой системы, но сделать вывод про linq2db и локальную сеть.

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

_>>Ну так разные будут запросы, т.к. синтаксис слегка отличается. Где-то будет limit, а где-то fetch first и т.п. )
I>То есть, ты предлагаешь писать код под каждую БД руками ?

Нет, естественно оно само делается. Через тот же самый механизм коннекторов (провайдеров). Вообще я не пойму с чего это фанаты .net считают данный очевиднейший архитектурный подход с "плагинами" под каждую СУБД привилегией linq ORM. С linq это никак не связано. Более того, данный подход использовался задолго до рождения linq.

_>>Не нужна перекомпиляция примеров. Я вроде как уже несколько раз показал это. )))
I>Ты ничего не показал. Покажи, как одна и та же строка запроса разворачивается в совершенно разный по структуре SQL.

Ну если ты мне подскажешь на каком запросе должна появиться подобная разная структура для пары sqlite и postgresql, то с удовольствием продемонстрирую тебе работающий код. Для других СУБД вряд ли, т.к. они у меня не установлены.

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

_>>Вообще то я продемонстрировал инструмент с удобством лучше linq. Хотя бы потому, что он является полным отражением sql. В отличие от linq, у которого нет полного взаимного соответствия с sql. Например как насчёт CTE запросов на linq? )
I>Достоинство linq как раз в том, что в нем нет взаимного соответствия с SQL. Именно из за этого он и интересен. Недостаток — вещи навроде CTE не поддерживаются.

Так в чём собственно достоинство то? ) А то формулировка "не как sql" вообще не катит (тем более при работе с sql СУБД).

_>>О, ещё один в 1000 соединений... Ты что, хочешь использовать схему apache с отдельным потоком на каждый запрос пользователя или как? )
I>Как думаешь, сколько соединений будет открыто на стороне DBMS, если с ним работает кластер из 10 веб-серверов ?

Нуу штучек 200 наверное (без пула) и соответственно это отожрёт мегабайт 200 оперативки сервера СУБД, которая при таком раскладе (обеспечение работы 10 серверов-приложения) будет скорее всего за 200 гигов... )))

_>>О да, они страшно редки. Особенно учитывая популярность mysql и то, что её оптимизация частенько крутится как раз вокруг правильной настройки кэша запросов (для веба, с его статической природой самое оно).
I>mysql это полу-база данных, у неё кривой оптимизатор, она без ручного тюнинга никогда нигде не применяется.
I>Её применяют массово из за стоимости, а не из за мега-профита.

Стоимость у неё одинаковая с тем же Postresql, а вот популярность очень разная. Mysql попопулярнее SQL Server будет, тогда как Postresql существенно отстаёт от них. Так что дело совсем не в цене, а в заточенности под определённые сценарии.

Но в любом случае это уже отвлечение от темы. Не важно по каким причинам и для какой аудитории популярно данное решение. Главное сам факт популярности, который опровергает слова моего оппонента о редкости использования.

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

_>>Ну так разные будут запросы, т.к. синтаксис слегка отличается. Где-то будет limit, а где-то fetch first и т.п. )
S>То есть ты должен учесть все возможные провайдеры.

Да, правильно. Точнее все возможные СУБД, с которыми мы обещаем работу. И в чём проблема?

_>>Не нужна перекомпиляция примеров. Я вроде как уже несколько раз показал это. )))
S> Вот появился новый провайдер SQLСупперНавороченный. А у тебя он не прописан.

Если в мире появится новая популярная СУБД и соответственно выйдет провайдер под неё и мы захотим добавить поддержку этой СУБД в наш продукт, то да, понадобится перекомпиляция (и плюс добавление ещё одной строчки в тот наш if). А теперь озвучь ка мне цифру, сколько популярных СУБД появилось в мире хотя бы за последний год. Ну чтобы понять насколько ужасно для разработчика данное требование...

S>Может выйти новая версия провайдера которая генерит более оптимальный SQL использующая CTE.

1. Как раз в данной библиотеке с CTE всё нормально.
2. В linq ORM работа с CTE и не предвидится.
3. Даже если предположить, что в linq ORM как-то добавили бы подобную возможность, то всё равно пришлось бы перекомпилировать проект, т.к. надо было бы переписывать соответствующие запросы.

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

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

_>>>Ну так разные будут запросы, т.к. синтаксис слегка отличается. Где-то будет limit, а где-то fetch first и т.п. )
S>>То есть ты должен учесть все возможные провайдеры.

_>Да, правильно. Точнее все возможные СУБД, с которыми мы обещаем работу. И в чём проблема?

_>>>Не нужна перекомпиляция примеров. Я вроде как уже несколько раз показал это. )))
S>> Вот появился новый провайдер SQLСупперНавороченный. А у тебя он не прописан.

_>Если в мире появится новая популярная СУБД и соответственно выйдет провайдер под неё и мы захотим добавить поддержку этой СУБД в наш продукт, то да, понадобится перекомпиляция (и плюс добавление ещё одной строчки в тот наш if). А теперь озвучь ка мне цифру, сколько популярных СУБД появилось в мире хотя бы за последний год. Ну чтобы понять насколько ужасно для разработчика данное требование...

Хренова туча NoSql.
S>>Может выйти новая версия провайдера которая генерит более оптимальный SQL использующая CTE.

_>1. Как раз в данной библиотеке с CTE всё нормально.
Но с каждой новой версий появляются новые инструкции. В том числе оптимизируются запросы.
_>2. В linq ORM работа с CTE и не предвидится.
Это твои домыслы. Вероятность есть даже сторонних провайдеров.
_>3. Даже если предположить, что в linq ORM как-то добавили бы подобную возможность, то всё равно пришлось бы перекомпилировать проект, т.к. надо было бы переписывать соответствующие запросы.

Для Linq как раз не надо, так как компиляция запросов динамическая, а за текст запроса отвечает провайдер.

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

_>>Ты про использование результатов запроса что ли? ) Ну это выглядит как-то так:
_>>

_>>for(auto& row: db(select(Table.a, Table.b).from(Table).where(Table.a>10))) cout<<row.a<<'\t'<<row.b<<endl;
_>>

_>>и естественно всё типизировано.
·>А какого типа тут будет row?

Нечто очень страшное. ))) Так что без использования auto программировать подобное было бы невозможно. )

·>Вот такой код скомпилируется?
·>

·>for(auto& row: db(select(Table.b).from(Table).where(Table.a>10))) cout<<row.a<<'\t'<<row.b<<endl;
·>

Нет. Более того, корректно обработаются и более сложные случаи, типа таких:

auto q=select(Table.a, Table.b.as(alias::x)).from(Table).where(Table.a>10).as(alias::q);
for(auto& row: db(select(q.a, q.x).from(q).where(q.x<0))) cout<<row.a<<'\t'<<row.x<<endl; //OK
for(auto& row: db(select(q.a, q.b).from(q).where(q.x<0))) cout<<row.a<<'\t'<<row.x<<endl; //Error
for(auto& row: db(select(q.a, q.x).from(q).where(q.b<0))) cout<<row.a<<'\t'<<row.x<<endl; //Error
for(auto& row: db(select(q.a, q.x).from(q).where(q.x<0))) cout<<row.a<<'\t'<<row.b<<endl; //Error

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

G>>>Про автопараметризацию забудь, она работает в таких примитивных случаях, что нет смысла обсуждать.
_>>И тут ты снова не прав, т.к. есть SET PARAMETERIZATION FORCED. Сразу скажу (а то тут есть некоторые любители домысливания за оппонентов), что я не призываю всё переделать под данную технику, а просто в очередной раз демонстрирую неверность твоих утверждений.
G>Ты демонстрируешь только свой профанизм.
G>Смотри что получается с FORCED:
G>1) В приложении ты клеишь сроки с параметрами и генерируешь 100500 однотипных, но разных с точки зрения РСУБД, запросов.
G>2) РСУБД парсит каждый запрос (это повторяется 100500 раз) и получает в итоге один параметризованный план
G>Не проще генерировать параметризованный запрос в приложении и не тратить время на парсинг?

Это просто феерично. Если посмотреть на что направлен мой комментарий и на что отвечаешь потом ты. Причём я даже специально тогда отметил для особо одарённых, что здесь исключительно возражение на твоё высказывание о возможности работы автопараметризации только в примитивных случаях, а не призыв её использования. И всё же даже после такого явного предупреждения ты пишешь подобную ересь. Да же не знаю что сказать на такое...

_>>Вообще то я продемонстрировал инструмент с удобством лучше linq. Хотя бы потому, что он является полным отражением sql. В отличие от linq, у которого нет полного взаимного соответствия с sql. Например как насчёт CTE запросов на linq? )
G>Я тебе еще раз повторяю, все что ты продемонстрировал не умеет динамически собирать запросы и не умеет генерировать разные запросы для разных движков.

И динамические запросы без проблем делаются (собственно это можно было увидеть даже просто из того факта, что там по два вида всех конструкций, динамические и обычные) и генерация разного кода для разных СУБД тоже без проблем работает (в точности по тому же принципу, через коннекторы/провайдеры). Если по твоему есть какие-то конкретные примеры sql кода (динамические или статические, не важно), которые ты считаешь не могут быть записаны с помощью данной библиотеки, то давай, озвучь их.

А готов ли ты записать любой sql код с помощью Linq? ) Если я возьму например какой-нибудь рекурсивный CTE запросик...

G>Я тебе приводил пример как в linq добавление условия в where мрже приводить к добавлению джоина. Без этого говноподелки бесполезны чуть более чем полностью.

А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.

_>>Ну т.е. у нас снова беседа свелась к оценки конкретных цифр. Т.е. никто не возражает что prepare эффективнее, остаётся только вопрос на сколько.
G>Ни на сколько, ты опять забываешь про накладные расходы которые несет prepared statement.
G>Ты думаешь если бы prepare был реально эффективнее, то его бы не использовали везде? Но по факту не используют.

Вообще то вполне себе используют. Не надо оценивать всех по своему маленькому мирку .net + SQLServer.

_>>Ну покажи где я такое предлагал. )))
G>Везде. Ты не говорил об ограничениях, это можно как-то по-другому понимать?

Вообще то изначально обсуждение касалось предкомпилированных запросов в linq2db, EF и т.п. И умеют ли они делать предкомпиляцию в СУБД (выяснилось что не умеют). Применимость самих предкомпилированных запросов linq2db, EF и т.п. мы тут не обсуждали, но очевидно, что их не используют повсеместно.

_>>О, ещё один в 1000 соединений... Ты что, хочешь использовать схему apache с отдельным потоком на каждый запрос пользователя или как? )
G>А при чем тут потоки? можно и с 50 потоками сгенерировать 100500 соединений. Более того, как раз асинхронная обработка запросов ограниченным пулом потоков как раз ведет к повышенной нагрузке на пул соединений.

Можно то можно. Только если начать обсуждать все теоретически возможные криворукие реализации, то подобная дискуссия точно ни к чему не приведёт.

G>>>Исключения настолько редки, что не имеет смысл их рассматривать.
_>>О да, они страшно редки. Особенно учитывая популярность mysql и то, что её оптимизация частенько крутится как раз вокруг правильной настройки кэша запросов (для веба, с его статической природой самое оно).
G>Для говносайтов с 1 посещением в месяц — отличная тема. Под нагрузкой не катит вообще. Ресурсы сервера БД сильно дороже, чем ресурсы отдельного сервера для кэша.
G>Но ты об этом никогда не узнаешь, у тебя не было и не будет ни одного проекта с серьезной нагрузкой.

А где был разговор про тяжёлую нагрузку или ещё что? Твоё утверждение было просто про редкость использования данного механизма. Что явно является бредом как раз из-за распространённости mysql (пускай её при этом и используют не для самых тяжёлых случаев).

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

_>>Если в мире появится новая популярная СУБД и соответственно выйдет провайдер под неё и мы захотим добавить поддержку этой СУБД в наш продукт, то да, понадобится перекомпиляция (и плюс добавление ещё одной строчки в тот наш if). А теперь озвучь ка мне цифру, сколько популярных СУБД появилось в мире хотя бы за последний год. Ну чтобы понять насколько ужасно для разработчика данное требование...
S> Хренова туча NoSql.

1. И какое это имеет отношение к библиотеке работы с sql СУБД? )))
2. А Linq2db умеет работать с какими-то nosql СУБД? )
3. Если переходить к nosql СУБД, то обычно в любом случае надо переделывать весь код, потому что используется вообще другая схема хранения данных.

S>>>Может выйти новая версия провайдера которая генерит более оптимальный SQL использующая CTE.
_>>1. Как раз в данной библиотеке с CTE всё нормально.
S> Но с каждой новой версий появляются новые инструкции. В том числе оптимизируются запросы.
_>>2. В linq ORM работа с CTE и не предвидится.
S> Это твои домыслы. Вероятность есть даже сторонних провайдеров.
_>>3. Даже если предположить, что в linq ORM как-то добавили бы подобную возможность, то всё равно пришлось бы перекомпилировать проект, т.к. надо было бы переписывать соответствующие запросы.
S> Для Linq как раз не надо, так как компиляция запросов динамическая, а за текст запроса отвечает провайдер.



Ты похоже вообще не понимаешь о чём пишешь. Нормальные CTE запросы не записываются на linq. Т.е. это не то что какие-то провайдеры плохие и не могут оттранслировать соответствующий код, а именно на linq не запишешь. Соответственно при решение подобных задач в приложение просто забивают на linq и записывают нужный запрос текстовой sql строкой. Так что если предположить чудо и появится какой-то способ записи таких выражений на linq, то точно придётся переписывать весь код.

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

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

_>>>Если в мире появится новая популярная СУБД и соответственно выйдет провайдер под неё и мы захотим добавить поддержку этой СУБД в наш продукт, то да, понадобится перекомпиляция (и плюс добавление ещё одной строчки в тот наш if). А теперь озвучь ка мне цифру, сколько популярных СУБД появилось в мире хотя бы за последний год. Ну чтобы понять насколько ужасно для разработчика данное требование...
S>> Хренова туча NoSql.

_>1. И какое это имеет отношение к библиотеке работы с sql СУБД? )))
То, что Linq to EF их поддерживает
https://github.com/aspnet/EntityFramework/wiki/Roadmap

Providers
◦Azure Table Storage
◦Redis
◦Other non-relational databases

_>2. А Linq2db умеет работать с какими-то nosql СУБД? )
Не знаю.

_>3. Если переходить к nosql СУБД, то обычно в любом случае надо переделывать весь код, потому что используется вообще другая схема хранения данных.

Linq не привязан вообще к БД

S>>>>Может выйти новая версия провайдера которая генерит более оптимальный SQL использующая CTE.
_>>>1. Как раз в данной библиотеке с CTE всё нормально.
S>> Но с каждой новой версий появляются новые инструкции. В том числе оптимизируются запросы.
_>>>2. В linq ORM работа с CTE и не предвидится.
S>> Это твои домыслы. Вероятность есть даже сторонних провайдеров.
_>>>3. Даже если предположить, что в linq ORM как-то добавили бы подобную возможность, то всё равно пришлось бы перекомпилировать проект, т.к. надо было бы переписывать соответствующие запросы.
S>> Для Linq как раз не надо, так как компиляция запросов динамическая, а за текст запроса отвечает провайдер.

_>

_>Ты похоже вообще не понимаешь о чём пишешь. Нормальные CTE запросы не записываются на linq. Т.е. это не то что какие-то провайдеры плохие и не могут оттранслировать соответствующий код, а именно на linq не запишешь. Соответственно при решение подобных задач в приложение просто забивают на linq и записывают нужный запрос текстовой sql строкой. Так что если предположить чудо и появится какой-то способ записи таких выражений на linq, то точно придётся переписывать весь код.

Как раз CTE легко ложатся на CTE так как вычисления ленивые и я могу одно выражение использовать в запросе несколько раз.
А это как раз хорошо ложится на SQL.
В том числе и динамические запросы. Еще раз динамических SQL куча и еще маленькая тележка, так как нужно отбирать по разным измерениям и варьируя их количество.

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

_>Ты похоже вообще не понимаешь о чём пишешь. Нормальные CTE запросы не записываются на linq.

На linq не записываются не CTE вообще, а одна конкретная их разновидность. Все же остальные CTE в рамках linq просто не нужны, так как это просто средство декомпозиции запроса, inline вариант user function, а возможности C# по декомпозиции на две головы выше таковых у SQL.

_>Соответственно при решение подобных задач в приложение просто забивают на linq

Далеко не всегда забивают. Есть много вариантов. В MSSQL, к примеру, можно использовать hierarchyid, что дает, помимо упрощения запросов, еще и очень большой плюс к перформансу на целом ряде операций.

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

_>2. В linq ORM работа с CTE и не предвидится.

Если нужно сгенерировать CTE, то это вообще-то совсем не проблема. Проблема с иерархическими запросами, которые делаются через CTE. И здесь дело обстоит примерно так. Необходимость в таких запросах возникает крайне редко. А сделать это исключительно в доказательство возможностей LINQ лично мне пока просто недосуг

Обходится это элементарно — делается view с внутри с CTE и дальше LINQ рулит как обычно.

У меня в текущем проекте таких view ровно один штука примерно но тысячу LINQ запросов. Т.е. 0.1%.

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

I>>Достоинство linq как раз в том, что в нем нет взаимного соответствия с SQL. Именно из за этого он и интересен. Недостаток — вещи навроде CTE не поддерживаются.

_>Так в чём собственно достоинство то? ) А то формулировка "не как sql" вообще не катит (тем более при работе с sql СУБД).

Структура запросов соответствуют структуре данных, а не структуре SQL конкретной базы.

_>Но в любом случае это уже отвлечение от темы. Не важно по каким причинам и для какой аудитории популярно данное решение. Главное сам факт популярности, который опровергает слова моего оппонента о редкости использования.

Ты забавно виляешь — когда тебе выгодно, рассказываешь про mysql, когда выгодно — перепрыгиваешь на высоконагруженые приложения.

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

_>>>Ну так разные будут запросы, т.к. синтаксис слегка отличается. Где-то будет limit, а где-то fetch first и т.п. )
I>>То есть, ты предлагаешь писать код под каждую БД руками ?

_>Нет, естественно оно само делается. Через тот же самый механизм коннекторов (провайдеров). Вообще я не пойму с чего это фанаты .net считают данный очевиднейший архитектурный подход с "плагинами" под каждую СУБД привилегией linq ORM. С linq это никак не связано. Более того, данный подход использовался задолго до рождения linq.

Ты нигде ни разу не показал, хотя бы теоретически, как один и тот же запрос в sqlpp развернется в sql с различной структурой.

I>>Ты ничего не показал. Покажи, как одна и та же строка запроса разворачивается в совершенно разный по структуре SQL.

_>Ну если ты мне подскажешь на каком запросе должна появиться подобная разная структура для пары sqlite и postgresql, то с удовольствием продемонстрирую тебе работающий код. Для других СУБД вряд ли, т.к. они у меня не установлены.

Работающий код совсем необязательно. Для linq тебе показали вагон примеров, которые дают совершенно разный по структуре SQL.
Вот и интересно, как sqlpp делает такой же фокус.

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

_>А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.

Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.

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

S>>> Хренова туча NoSql.
_>>1. И какое это имеет отношение к библиотеке работы с sql СУБД? )))
S> То, что Linq to EF их поддерживает

Вообще то в данном обсуждение речь шла о C++ библиотечке, ну да ладно, давай поговорим про EF, так даже забавнее. )))

S>https://github.com/aspnet/EntityFramework/wiki/Roadmap
S>

S>Providers
S>◦Azure Table Storage
S>◦Redis
S>◦Other non-relational databases

Интересно, а ты сам то хотя бы читаешь текст по своим же ссылкам? ) Roadmap на EF Core (причём в разделе "может быть когда-нибудь") — это конечно сильно. )))

_>>3. Если переходить к nosql СУБД, то обычно в любом случае надо переделывать весь код, потому что используется вообще другая схема хранения данных.
S> Linq не привязан вообще к БД

Ну давай, расскажи как ты будешь удобно работать скажем с графовой СУБД (например Neo4j) с помощью Linq. )))

_>>Ты похоже вообще не понимаешь о чём пишешь. Нормальные CTE запросы не записываются на linq. Т.е. это не то что какие-то провайдеры плохие и не могут оттранслировать соответствующий код, а именно на linq не запишешь. Соответственно при решение подобных задач в приложение просто забивают на linq и записывают нужный запрос текстовой sql строкой. Так что если предположить чудо и появится какой-то способ записи таких выражений на linq, то точно придётся переписывать весь код.
S> Как раз CTE легко ложатся на CTE так как вычисления ленивые и я могу одно выражение использовать в запросе несколько раз.
S>А это как раз хорошо ложится на SQL.
S>В том числе и динамические запросы. Еще раз динамических SQL куча и еще маленькая тележка, так как нужно отбирать по разным измерениям и варьируя их количество.

Интересно, хоть кто-нибудь в данной темке способен расшифровать и пересказать человеческим языком данный текст? )

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

_>>2. В linq ORM работа с CTE и не предвидится.
IT>Если нужно сгенерировать CTE, то это вообще-то совсем не проблема. Проблема с иерархическими запросами, которые делаются через CTE. И здесь дело обстоит примерно так. Необходимость в таких запросах возникает крайне редко. А сделать это исключительно в доказательство возможностей LINQ лично мне пока просто недосуг
IT>Обходится это элементарно — делается view с внутри с CTE и дальше LINQ рулит как обычно.

Ну т.е. "обход" заключается в записи запроса через голую sql строку (не важно каждый раз или один раз при создание view), как я собственно и говорил. )))

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

I>>>Достоинство linq как раз в том, что в нем нет взаимного соответствия с SQL. Именно из за этого он и интересен. Недостаток — вещи навроде CTE не поддерживаются.
_>>Так в чём собственно достоинство то? ) А то формулировка "не как sql" вообще не катит (тем более при работе с sql СУБД).
I>Структура запросов соответствуют структуре данных, а не структуре SQL конкретной базы.

Т.е. ты считаешь, что язык SQL не очень хорошо подходит для работы с реляционными СУБД? ) Я правильно понял твою мысль? )

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

_>>Ну если ты мне подскажешь на каком запросе должна появиться подобная разная структура для пары sqlite и postgresql, то с удовольствием продемонстрирую тебе работающий код. Для других СУБД вряд ли, т.к. они у меня не установлены.
I>Работающий код совсем необязательно. Для linq тебе показали вагон примеров, которые дают совершенно разный по структуре SQL.
I>Вот и интересно, как sqlpp делает такой же фокус.

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

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

_>>А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.
L>Вот это действительно феерично. Реальные запросы иногда включают десятки джоинов. Я бы с интересом посмотрел, как программист будет оценивать их сложность по одному взгляду. Про вред преждевременной оптимизации и говорить не стоит, видимо.

Если у нас сложится ситуация, в которой программист не способен проанализировать находящийся перед глазами sql запрос (не важно по причине слабости программист или же дикой сложности запроса), то запись этого же запроса с помощью Linq только ещё больше ухудшит данную ситуацию.