Re[11]: Тормознутость и кривость linq - Компьютерные священные войны

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

_>Ты говоришь о чём-то вроде такого
_>

_>auto F() {return select(users.id, users.name).from(users).where(users.total>total).as(rich_users);}

_>auto q=F();
_>for(const auto& row: db(select(orders.user).from(orders.join(q).on(orders.user==q.id)).where(orders.year>year))){
_>    //...
_>}
_>

_>кода?

Покажи, как это делать в с++. Намекать "илиментарщина" не надо. В C# это работает через ExpresstionTree. Чем ты заменишь этот механизм в С++ ?

Один и тот же вопрос, твои ответы
"ценой диких извратов внутри библиотеки"

"как в таких тривиальных вещах можно видеть что-то сложное и думать что реализация подобной элементарщины — это какой-то высокий уровень."

Вывод напрашивается сам собой

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

_>>Ты говоришь о чём-то вроде такого
_>>

_>>auto F() {return select(users.id, users.name).from(users).where(users.total>total).as(rich_users);}

_>>auto q=F();
_>>for(const auto& row: db(select(orders.user).from(orders.join(q).on(orders.user==q.id)).where(orders.year>year))){
_>>    //...
_>>}
_>>

_>>кода?
I>Покажи, как это делать в с++. Намекать "илиментарщина" не надо.

Приблизительно так:

#include <sqlpp11/sqlpp11.h>

I>В C# это работает через ExpresstionTree. Чем ты заменишь этот механизм в С++ ?

Вообще то построение деревьев выражений в C++ возможно уже давным давно. Более того, насколько я помню Евгений уже даже когда-то показывал тебе элементарные примеры подобного. Конечно оно выглядит совсем не изящно и лаконично, так что авторам библиотек на базе данной техники приходится поднапрячься. Зато у пользователей таких библиотек никаких проблем нет — удобство не меньше чем у linq вариантов (ну а эффективность очевидно лучше по определению).

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

_>Приблизительно так:
_>

_>#include <sqlpp11/sqlpp11.h>
_>

Непонятно. Что там унутре, какая механика ? Те самые "илиментарные дикие извраты" ?
Если это генератор SQL, то это сходу сливает linq, ибо linq это более общий механизм, можно на лету генерить что хошь, в зависимости от сервера.
Хочешь — sql, хочешь — odata, хочешь — no-sql, а хочешь — прямо по коллекциям бегай. Никаких проблем.

I>>В C# это работает через ExpresstionTree. Чем ты заменишь этот механизм в С++ ?

_>Вообще то построение деревьев выражений в C++ возможно уже давным давно. Более того, насколько я помню Евгений уже даже когда-то показывал тебе элементарные примеры подобного. Конечно оно выглядит совсем не изящно и лаконично, так что авторам библиотек на базе данной техники приходится поднапрячься. Зато у пользователей таких библиотек никаких проблем нет — удобство не меньше чем у linq вариантов (ну а эффективность очевидно лучше по определению).

А, ну ясно, "илиментарные дикие извраты" что даже авторам либы надо поднапрячься.
То есть, любой нестандартный кейс или расширение или оптимизация сразу идут лесом.

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

_>>Приблизительно так:
_>>

_>>#include <sqlpp11/sqlpp11.h>
_>>

I>Непонятно. Что там унутре, какая механика ? Те самые "илиментарные дикие извраты" ?

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

Что касается "элементарно" и "извраты", то это относилось к разным вещам. Извраты требуются для организации самого процесса работы с соответствующими деревьями выражений. Т.е. сложно задать самый базис, реализующий самый простенький select. Но если уж ты это осилишь, то дальше всё становится тривиально. Т.е. при уже работающем механизме создание простого запроса, добавить возможность создания join (про которую говорил мой собеседник) элементарно.

I>Если это генератор SQL, то это сходу сливает linq, ибо linq это более общий механизм, можно на лету генерить что хошь, в зависимости от сервера.
I>Хочешь — sql, хочешь — odata, хочешь — no-sql, а хочешь — прямо по коллекциям бегай. Никаких проблем.

С linq данную библиотеку никто не сравнивал. Сравнивают с linq2sql и аналогами. Так что не надо демагогии.

I>А, ну ясно, "илиментарные дикие извраты" что даже авторам либы надо поднапрячься.
I>То есть, любой нестандартный кейс или расширение или оптимизация сразу идут лесом.

Ну если ты не знаком с метапрограммированием на шаблонах C++, то да, за расширение этот библиотеки браться не стоит. )))

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

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

Потребуется. Для работы с деревьями выражений — допиливание, расширение, оптимизация и тд и тд и тд. Это часто случается при работе с данными — кеширование, оптимизации и прочие вещи никто не отменял.

I>>Если это генератор SQL, то это сходу сливает linq, ибо linq это более общий механизм, можно на лету генерить что хошь, в зависимости от сервера.
I>>Хочешь — sql, хочешь — odata, хочешь — no-sql, а хочешь — прямо по коллекциям бегай. Никаких проблем.

_>С linq данную библиотеку никто не сравнивал. Сравнивают с linq2sql и аналогами. Так что не надо демагогии.

Если речь про sql, odata, no-sql то ежу понятно, что речь про linq-провайдер. linq2sql именно такой и есть.

I>>А, ну ясно, "илиментарные дикие извраты" что даже авторам либы надо поднапрячься.
I>>То есть, любой нестандартный кейс или расширение или оптимизация сразу идут лесом.
_>Ну если ты не знаком с метапрограммированием на шаблонах C++, то да, за расширение этот библиотеки браться не стоит. )))

Вот-вот. Как видишь, библиотека "не для всех". А то вдруг понадобится специальный случай кеширования, и всё, приехали.

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

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

И много тебе пришлось написать расширений для linq2sql или EF? )

_>>Ну если ты не знаком с метапрограммированием на шаблонах C++, то да, за расширение этот библиотеки браться не стоит. )))
I>Вот-вот. Как видишь, библиотека "не для всех". А то вдруг понадобится специальный случай кеширования, и всё, приехали.

Ну лично для меня не будет никакого "всё, приехали", даже если вдруг понадобится. В чём я впрочем сильно сомневаюсь. )

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

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

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

_>И много тебе пришлось написать расширений для linq2sql или EF? )

Я расширял другой провайдер.

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

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

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

_>И много тебе пришлось написать расширений для linq2sql или EF? )

https://www.simple-talk.com/dotnet/.net-framework/giving-clarity-to-linq-queries-by-extending-expressions/
https://github.com/scottksmith95/LINQKit
http://www.albahari.com/nutshell/predicatebuilder.aspx
http://www.albahari.com/nutshell/linqkit.aspx

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

_>кода? Не пойму как в таких тривиальных вещах можно видеть что-то сложное и думать что реализация подобной элементарщины — это какой-то высокий уровень. )))

Покажи теперь SQL

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

_>>кода? Не пойму как в таких тривиальных вещах можно видеть что-то сложное и думать что реализация подобной элементарщины — это какой-то высокий уровень. )))
D>Покажи теперь SQL

Для данного кода MockDb (это такой провайдер, который тупо печатает стандартизированный sql и всё) выдаёт следующее (для других СУБД могут быть нюансы, хотя наверное не с этим примером):

Running select call with
SELECT Orders.user FROM Orders INNER  JOIN SELECT Users.id,Users.name FROM Users WHERE (Users.total>10) AS rich_users ON (Orders.user=rich_users.id) WHERE (Orders.year>100)

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

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

_>>>кода? Не пойму как в таких тривиальных вещах можно видеть что-то сложное и думать что реализация подобной элементарщины — это какой-то высокий уровень. )))
D>>Покажи теперь SQL

_>Для данного кода MockDb (это такой провайдер, который тупо печатает стандартизированный sql и всё) выдаёт следующее (для других СУБД могут быть нюансы, хотя наверное не с этим примером):
_>

_>Running select call with
_>SELECT Orders.user FROM Orders INNER  JOIN SELECT Users.id,Users.name FROM Users WHERE (Users.total>10) AS rich_users ON (Orders.user=rich_users.id) WHERE (Orders.year>100)
_>

Из этого простого примера видно что строить, а тем более оптимизировать SQL оно не умеет.
Поставить еще одно Where вокруг всего вот этого выражения — и думаю появится новый сабселект.
Можна надеяться на оптимизатор SQL Server, но черт, он то как оказывается не резиновый.

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

_>>Для данного кода MockDb (это такой провайдер, который тупо печатает стандартизированный sql и всё) выдаёт следующее (для других СУБД могут быть нюансы, хотя наверное не с этим примером):
_>>

_>>Running select call with
_>>SELECT Orders.user FROM Orders INNER  JOIN SELECT Users.id,Users.name FROM Users WHERE (Users.total>10) AS rich_users ON (Orders.user=rich_users.id) WHERE (Orders.year>100)
_>>

D>Из этого простого примера видно что строить, а тем более оптимизировать SQL оно не умеет.

Оптимизировать никто и не обещал. Это инструмент для тех, кто знаком с sql. )))

А что по твоему не так с построением? ))) Ты видишь какое-то несоответствие заданной конструкции и полученной sql строки? )

D>Поставить еще одно Where вокруг всего вот этого выражения — и думаю появится новый сабселект.

А вот такого естественно не будет, т.к. дополнительный select появится только в случае прямого указания на это. Т.е. данный инструмент делает в точности то, что указывает программист. Не больше и не меньше. )

D>Можна надеяться на оптимизатор SQL Server, но черт, он то как оказывается не резиновый.

Скорее уж PostgreSQL или Oracle в особых случаях. )))

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

_>А вот такого естественно не будет, т.к. дополнительный select появится только в случае прямого указания на это.
Почему "естественно"? Тут подселект на ровном месте вылез. Да еще и с использованием колонки, которая не используется в запросе.
Еще один-два подобных подселекта и не план будет, а слезы.

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

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

_>>>Для данного кода MockDb (это такой провайдер, который тупо печатает стандартизированный sql и всё) выдаёт следующее (для других СУБД могут быть нюансы, хотя наверное не с этим примером):
_>>>

_>>>Running select call with
_>>>SELECT Orders.user FROM Orders INNER  JOIN SELECT Users.id,Users.name FROM Users WHERE (Users.total>10) AS rich_users ON (Orders.user=rich_users.id) WHERE (Orders.year>100)
_>>>

D>>Из этого простого примера видно что строить, а тем более оптимизировать SQL оно не умеет.

_>Оптимизировать никто и не обещал. Это инструмент для тех, кто знаком с sql. )))

_>А что по твоему не так с построением? ))) Ты видишь какое-то несоответствие заданной конструкции и полученной sql строки? )

D>>Поставить еще одно Where вокруг всего вот этого выражения — и думаю появится новый сабселект.

_>А вот такого естественно не будет, т.к. дополнительный select появится только в случае прямого указания на это. Т.е. данный инструмент делает в точности то, что указывает программист. Не больше и не меньше. )

D>>Можна надеяться на оптимизатор SQL Server, но черт, он то как оказывается не резиновый.

_>Скорее уж PostgreSQL или Oracle в особых случаях. )))

linq2db делает именно то что мне нужно — правильно строит SQL. А умная статическая склейка строк — хватит наплавался в этом болоте.
Я доводил тебя до того момента чтобы показать как реально используется linq2db в моих проектах.

Пишется фукнкция которая возвращает, например проекты (5 джоинов на разные таблицы) — ну прям stored proc, назовем ее GetProjects()
Пишется вторая функция, котрая например возвращает пользователей к которым ты имеешь доступ (users where assignment_id = userId)) — будет GetMyUsers(userId)
Теперь тебе надо проекты которые ты можешь видеть GetMyVisibleProjects(userId)
```
from p in GetProjects()
join u in GetMyUsers(userId) on p.user_id equals u.user_id
select p
```

Вернем c помощью это функции что-то

GetMyVisibleprojects(userId)
  .Where(p => p.ProjectDate > "1-1-2015") // опа, еще бы фильтрануть
  .Select(p => p.Department) // в САМОМ конце решаем что нам просто нужны уникальные департменты и только 20 по смещению 100
  .Distinct() 
  .Skip(100)
  .Take(20)

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

То, что я могу логику разнести по функциям без потери производительности SQL, делает linq для меня просто сказкой.
Во многих случаях я к черту выкидываю хранимки и переписываю их на linq2db

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

_>Оптимизировать никто и не обещал. Это инструмент для тех, кто знаком с sql. )))
_>А вот такого естественно не будет, т.к. дополнительный select появится только в случае прямого указания на это. Т.е. данный инструмент делает в точности то, что указывает программист. Не больше и не меньше. )

То есть, твой плюсовый код придется переписать целиком и полностью под каждый сервер базы данных, ибо мулька не умеет оптимизировать

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

_>>А вот такого естественно не будет, т.к. дополнительный select появится только в случае прямого указания на это.
_AB>Почему "естественно"? Тут подселект на ровном месте вылез. Да еще и с использованием колонки, которая не используется в запросе.
_AB>Еще один-два подобных подселекта и не план будет, а слезы.

Не будет потому, что их не будет в задающем коде. Т.е. сколько в коде select, столько их и в sql. Какие поля программист задал для запроса, такие и записаны в sql. Т.е. инструмент выдаёт ровно в точности то, что хотел сказать программист. Не больше (кривой код он не оптимизирует), и не меньше (своего бреда не вставит).

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

_>Не будет потому, что их не будет в задающем коде. Т.е. сколько в коде select, столько их и в sql. Какие поля программист задал для запроса, такие и записаны в sql.
А если в склеенном запросе эти поля не нужны? Создавать под этот запрос другую функцию?
Вот в твоем примере users.name не нужен и может существенно ухудшить план.

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

Ты можешь вот это вот, "код" вынести в функцию и заджоинится на нее и получить нормальный SQL?

Пока твой ответ — нет, не можешь. Вынести в функцию можешь (хотя какой в этом смысл?), заджойниться можешь,
получить нормальный SQL не можешь даже в тривиальном случае.

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

D>linq2db делает именно то что мне нужно — правильно строит SQL. А умная статическая склейка строк — хватит наплавался в этом болоте.
D>Я доводил тебя до того момента чтобы показать как реально используется linq2db в моих проектах.
D>

Пишется фукнкция которая возвращает, например проекты (5 джоинов на разные таблицы) — ну прям stored proc, назовем ее GetProjects()
D>

Пишется вторая функция, котрая например возвращает пользователей к которым ты имеешь доступ (users where assignment_id = userId)) — будет GetMyUsers(userId)
D>

Теперь тебе надо проекты которые ты можешь видеть GetMyVisibleProjects(userId)
D>

D>from p in GetProjects()
D>join u in GetMyUsers(userId) on p.user_id equals u.user_id
D>select p
D>

Вернем c помощью это функции что-то
D>

D>GetMyVisibleprojects(userId)
D>  .Where(p => p.ProjectDate > "1-1-2015") // опа, еще бы фильтрануть
D>  .Select(p => p.Department) // в САМОМ конце решаем что нам просто нужны уникальные департменты и только 20 по смещению 100
D>  .Distinct() 
D>  .Skip(100)
D>  .Take(20)
D>

D>Так вот, я представить себе не могу что склеит твой склейщик строк в этом случае.
D>А я вот точно знаю что у меня даже лишнего сабселекта не будет.

Так а зачем что-то представлять, предполагать и т.п... Давай сравним всё на практике, в реальности) Благо это не более 1-2 минут потребует. Запиши конкретный пример linq кода, который хочешь проверить и плюс приложи sql, который он генерирует. Ну а я в ответ покажу аналогичный код с помощью данной библиотечки и sql, который он сгенерирует. И сравним. А то пока от тебя в этой темке наблюдаются исключительно фантазии (например ты высказался что данный инструмент "не умеет генерировать sql", но правильный вариант что-то не продемонстрировал).

D>То, что я могу логику разнести по функциям без потери производительности SQL, делает linq для меня просто сказкой.

Угу, в работе запроса в СУБД потери производительности нет. А вот в формирование запроса в твоём коде появляются накладные расходы превышающие время исполнения всего запроса. )))

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

_>>Оптимизировать никто и не обещал. Это инструмент для тех, кто знаком с sql. )))
_>>А вот такого естественно не будет, т.к. дополнительный select появится только в случае прямого указания на это. Т.е. данный инструмент делает в точности то, что указывает программист. Не больше и не меньше. )
I>То есть, твой плюсовый код придется переписать целиком и полностью под каждый сервер базы данных, ибо мулька не умеет оптимизировать

Не путай оптимизацию кода (т.е. исправления косяков программиста, создавшего кривой sql) и адаптацию под особенности синтаксиса конкретной СУБД. Последнее естественно имеется, т.к. иначе собственно ничего и не работало бы.

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

_>>Не будет потому, что их не будет в задающем коде. Т.е. сколько в коде select, столько их и в sql. Какие поля программист задал для запроса, такие и записаны в sql.
_AB>А если в склеенном запросе эти поля не нужны? Создавать под этот запрос другую функцию?
_AB>Вот в твоем примере users.name не нужен и может существенно ухудшить план.

Это был форумный пример (причём в стиле "а можешь ли вот прямо к той строчке приделать сверху ещё и join"), а не реальный код. Естественно, что в реальном проекте подобного бреда не будет.

_>>Т.е. инструмент выдаёт ровно в точности то, что хотел сказать программист. Не больше (кривой код он не оптимизирует), и не меньше (своего бреда не вставит).
_AB>Другими словами, это чуть более продвинутая (но такая же тупая) склейка строк. Тебе об этом и говорят.

Вообще то, то, что это склейка строк я сам изначально и писал. Только не такая уж и тупая, т.к. гарантирует корректность получаемого sql (включая адаптацию под конкретные СУБД), типизацию параметров и результатов. Причём всё это во время компиляции, а не перед каждым запросом, как у обсуждаемых аналогов. Лично мне большего для работы с SQL БД и не требуется.

_AB>

_AB>Ты можешь вот это вот, "код" вынести в функцию и заджоинится на нее и получить нормальный SQL?

_AB>Пока твой ответ — нет, не можешь. Вынести в функцию можешь (хотя какой в этом смысл?), заджойниться можешь,
_AB>получить нормальный SQL не можешь даже в тривиальном случае.

Я — могу. Так же как и любой, знакомый с языком SQL. ))) Ну а для неосиливших SQL действительно стоит поискать другие инструменты. )

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	30.03.16 14:57
Оценка:

	От:	alex_public
	Дата:	30.03.16 17:51
	Оценка:	+1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	30.03.16 17:59
Оценка:

	От:	alex_public
	Дата:	30.03.16 19:33
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	31.03.16 08:17
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	01.04.16 05:42
Оценка:

	От:	Danchik
	Дата:	06.04.16 10:11
	Оценка:

	От:	Danchik
	Дата:	07.04.16 10:32
	Оценка:	+1

	От:	_ABC_
	Дата:	07.04.16 14:07
	Оценка:	+1

	От:	Danchik
	Дата:	07.04.16 14:19
	Оценка:	+1