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

_>Примера sql кода, ради написание которого на С++ по твоим словам "приходится вставать раком". "ad-hoc типы" — это у нас уже такой sql код? )

select a, b, c from Table

_>>>Ну IT сказал, что linq2db не умеет. И кому мне верить? )
НС>>Цитату не затруднит?
_>http://rsdn.ru/forum/flame.comp/6434532.1

Автор: IT
Дата: 03.05.16

Там нет такого утверждения.

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


_>Приложение с 1000 разных статических запросов к СУБД? ) Это было бы любопытно взглянуть на подобного эпичного монстра... )))

Это не монстры, а обычные ERP базы. С кучей справочников, документов, регистров, бизнесс-процессов, субконто итд

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

S>>Выглядит опасненько.Кроме того, я подозреваю, что сами prepared statements таки тоже создают ненулевую нагрузку на сервер — и если мы будем держать по 1000 statements на каждое подключение, то можем на это нарваться.

_>Приложение с 1000 разных статических запросов к СУБД? ) Это было бы любопытно взглянуть на подобного эпичного монстра... )))

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

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

_>Приложение с 1000 разных статических запросов к СУБД? ) Это было бы любопытно взглянуть на подобного эпичного монстра... )))

1000 запросов это эпичный монстр?

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

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

Несколько сотен это еще весьма скромное по размеру приложение.

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

_>Приложение с 1000 разных статических запросов к СУБД? ) Это было бы любопытно взглянуть на подобного эпичного монстра... )))
You made my day...

Не, я и так подозревал, что ты дальше двух шагов от наколенных поделок для персонального пользования в плане использования СУБД
не отходил, но блин... Как смешно, всё-таки.

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

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

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

P.S. Я тут с удовольствием наблюдаю за небольшой истерикой некоторых фанатов .net'а в ответ на это твоё сообщение. Жалкие попытки перехода на личности ясно дают понять о полном отсутствие каких-либо технических аргументов у оппонентов. Данный их слив является хорошим и показательным завершением дискуссии.

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

_>>Что-то я не могу из твоего мутного текста понять твою точку зрения. Так по твоему предкомпилированные запросы имеют смысл или нет? )))
S> Какой в них смысл если может смениться провайдер. В том числе изменения могут коснуться и самого провайдера. При этом оптимальным может быть уже другой запрос. А к динамическим так и подавно нет смысла

Т.е. в linq2db, EF и т.п. не стоило их делать? )

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

S>>> Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку
_>>Во многих задачах по другому просто нельзя.
S> Только такие задачи немассовые, единичные. А Linq как раз для широких масс.

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

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

_>>Приложение с 1000 разных статических запросов к СУБД? ) Это было бы любопытно взглянуть на подобного эпичного монстра... )))
S>Это не монстры, а обычные ERP базы. С кучей справочников, документов, регистров, бизнесс-процессов, субконто итд

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

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Примера sql кода, ради написание которого на С++ по твоим словам "приходится вставать раком". "ad-hoc типы" — это у нас уже такой sql код? )
НС>

select a, b, c from Table

ОК, на C++ это запишется так:

select(Table.a, Table.b, Table.c).from(Table)

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

_>>>>Ну IT сказал, что linq2db не умеет. И кому мне верить? )
НС>>>Цитату не затруднит?
_>>http://rsdn.ru/forum/flame.comp/6434532.1

Автор: IT
Дата: 03.05.16

НС>Там нет такого утверждения.

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

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

_>Теперь жду от тебя пояснений, где ты видишь в данной строчке "вставание раком".

На выходе то у тебя какой тип будет? Безликий tuple, да? Или вообще нетипизированная хрень?

_> Тебе самому то не стыдно выставлять себя на посмешище

Да тут над твоим воинствующим дилетантизмом все участники топика ржут давно, а ты все пытаешься стрелки перевести.

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

_>У тебя (и не только у тебя, но ещё и у некоторых забавных товарищей, отписавшихся после тебя) похоже какие-то проблемы с чтением. У меня вроде как вполне ясно было написано, что речь не о всех запросах в приложение, а только о статических, для которых полезна предкомпиляция.

Нет, это у тебя проблемы со знанием предметной области. По моему опыту, в типичном ERP приложении примерно 90% запросов не содержат динамических ветвлений. Так что 1000 запросов это вообще ни о чем.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Теперь жду от тебя пояснений, где ты видишь в данной строчке "вставание раком".
НС>На выходе то у тебя какой тип будет? Безликий tuple, да? Или вообще нетипизированная хрень?

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

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

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

_>> Тебе самому то не стыдно выставлять себя на посмешище
НС>Да тут над твоим воинствующим дилетантизмом все участники топика ржут давно, а ты все пытаешься стрелки перевести.

И снова ты ничего не смог ответить по сути вопроса (обсуждались то предкомпилированные запросы, а не что-то другое, но ты подправил цитирование так, чтобы постараться скрыть это), но зато попытался перейти на личности. Сам то представляешь как это выглядит со стороны?

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

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Теперь жду от тебя пояснений, где ты видишь в данной строчке "вставание раком".
НС>На выходе то у тебя какой тип будет? Безликий tuple, да? Или вообще нетипизированная хрень?

Во время компиляции генерируется структура с полями нужных типов и с нужными именами.
Простейший пример

Автор: Evgeny.Panasyuk
Дата: 22.04.15

:

    auto x = select(table.id, table.value);
    x.id = 11;
    x.value = 0.11;
    x.flag = true; // error

    auto y = select(table.id, table.flag);
    y.id = 11;
    y.value = 0.11; // error
    y.flag = true;

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Дело не в скобочках. Дело в том что в С++ тебе приходится вставать раком, чтобы описать простейщие для SQL конструкции. Тебя не случайно постоянно тыкают, как котенка, в проекции. Нет в С++ ad-hoc типов. А в SQL в основном они есть. И в шарпе соотвествующие типы присутствуют. Но в обычном шарпе даже промежуточные типы приходится раскрывать руками. А вот в query comprehension эти типы скрыты и синтаксический шум убран.

Что ты называешь ad-hoc типом? Что-то типа возврата выражением select(table1.a, table2.b) значения типа у которого внутри поля с именами a и b?
Если так, то эти ad-hoc типы есть, причём даже в C++1998

НС>Но для того чтобы это увидеть, надо иметь хотя бы желание разобраться. А если желания нет — вот тогда и кажется, что разница только в наличии скобочек.

Ага, точно, у кого-то нет желания разобраться

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

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

_>>>Приложение с 1000 разных статических запросов к СУБД? ) Это было бы любопытно взглянуть на подобного эпичного монстра... )))
S>>Это не монстры, а обычные ERP базы. С кучей справочников, документов, регистров, бизнесс-процессов, субконто итд

_>У тебя (и не только у тебя, но ещё и у некоторых забавных товарищей, отписавшихся после тебя) похоже какие-то проблемы с чтением. У меня вроде как вполне ясно было написано, что речь не о всех запросах в приложение, а только о статических, для которых полезна предкомпиляция. Если у тебя в приложение будут тысячи именно таких запросов, то у меня для тебя есть плохие новости об устройстве твоего приложения... )))
Угу и как это поможет при смене БД? А речь то шла о том, что бы держать соединение и SQLCommamd ради prepare запросов. Кстати статистика собирается и планы запросов могут меняться при работе 7*24
На счет статических запросах только по ID, то да там под тысячу. Если брать еще другие типа по наименованию, по коду, по номеру и дате, остатки по измерениям итд то там и десятки тысяч.
Ты наверное только с базами на 3 таблички работал?

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

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

S>>>> Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку
_>>>Во многих задачах по другому просто нельзя.
S>> Только такие задачи немассовые, единичные. А Linq как раз для широких масс.

_>1. Даже если предположить, что это так и есть, то какой вывод то? ) Или тебе может привиделось, что я предлагаю использовать ассемблер в бухгалтерии? )))
_>2. Ты в чём считаешь то массовость? ) В количестве проектов или в количестве пользователей? ) Потому как если смотреть на второе, то ситуация будет как раз обратная (эти самые задачи с миллисекундами имеются на каждом компьютере, в отличие от какой-нибудь бухгалтерии).
Количество проектов и количество пользователей. Ты любое предприятие возьми, там бухгалтерия это малая толика. Обычно она стоит отдельно и в неё выгружают данные. А вот все бизнес процессы коих огромное количество ведут в базах как ты называешь ERP.
Сразу видно, что ты теоретик

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

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

_>>>Что-то я не могу из твоего мутного текста понять твою точку зрения. Так по твоему предкомпилированные запросы имеют смысл или нет? )))

S>> Какой в них смысл если может смениться провайдер. В том числе изменения могут коснуться и самого провайдера. При этом оптимальным может быть уже другой запрос. А к динамическим так и подавно нет смысла

_>Т.е. в linq2db, EF и т.п. не стоило их делать? )
Что не стоило? Стоит делать компиляцию в ран таййме. А вот твоя статическая идет лесом.
Если ты говоришь о prepare, то они и так компилятся и хранятся в кэше. А поиск идет по тексту запроса. Или ты считаешь, что поисх в Хэш таблице это и есть бутылочное горлышко по сравнению двоичного поиска в базе? Вот кстати сравнение Словаря и деревьев в конце http://rsdn.ru/article/alg/tlsd.xml

Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.

Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ночной Смотрящий, Вы писали:
_>Ты про использование результатов запроса что ли? ) Ну это выглядит как-то так:
_>

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

_>И снова ты ничего не смог ответить по сути вопроса (обсуждались то предкомпилированные запросы, а не что-то другое, но ты подправил цитирование так, чтобы постараться скрыть это), но зато попытался перейти на личности.

То есть тебе можно на личности переходить, а когда тебе это возращают в ответ, то это уже криминал? Ну ну.