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

I>>К твоему сведению, это свойство не питона,а любого динамического языка.
I>>Для C# есть консоли всякие, но только дебаговые linq2pad. Собственно web .Net приложения могут компилироваться на лету, после деплоймента.

_>Ты похоже не понял о чём речь. Я говорю не про различие между интерпретируемым и компилируемым языком. Речь о лишнем синтаксическом мусоре типа класса приложения, функции main и т.п.

Еще раз — консоль все это прячет. Раскрой глаза — linqpad может работать безо всяких main и классов.

I>>Вобщем, именно про питон ты ровно ничего не показал
_>Ну на самом деле в данном примере были различные интересные особенности именно Питона (там и декораторы и менеджеры контента (with) и ещё некоторые нюансы), а не просто скриптового языка. Но если сравнивать с C#, то любой нормальный скриптовой будет удобнее в данной области. )))

Это общие слова.

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

I>>Вот здесь подробнее:
I>>http://programmers.stackexchange.com/questions/142065/creating-database-connections-do-it-once-or-for-each-query
I>>В джаве ровно так же, и вообще везде практически так же.

_>Ты хоть сам то читаешь то, на что кидаешь ссылки?

Именно. Ты, похоже, даже не понял, что сам же предложил и что тебе ответили
Поскольку ты очень плохо читаешь и забываешь контекст, я выделил

"Конечно.

Есть такая штука как Connection Pool.

Она замечательно решает проблему новых подключений на каждый запрос/группу запросов.

Деражать подключение открытым между запросами ради Prepare абсолютно точно плохая идея.

"

То есть, речь изначально шла про коннекшн пул ! Ты сам это видишь ?
То есть, речь не про удержания подключения вообще, а именно про удержание ради Prepare-Execute.
В многопоточной среде на такие фокусы никакого коннекшн пула не хватит.

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

_>Так приведи пример хоть одной такой SQL конструкции.

Я же вроде ясно чуть выше написал — ad-hoc типы.

_>Ну а потом наоборот сделаем. Я приведу пример какой-нибудь SQL конструкции (например рекурсивного CTE запроса)

Ну то есть ты увидел у IT про проблемы с CTE, и теперь машешь этим флагом, как будто это не единичный случай, а норма?

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

_>Да не про то речь. ))) Вот класс Program и функция Main вот прямо в этом твоём коде. Без них можно (пример Ikemefula был без них) или нет?

А при чем тут динамика?

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

_>>Какое интересно автодополнение ты видишь в данном примере? )
S> Все методы put,mount итд
S>

S>lcd("project")
S>    .mount("-t tmpfs -o size=500M tmpfs /mnt/ramdisk")
S>    .mkdir("/mnt/ramdisk/project")
S>    .cd("/mnt/ramdisk/project"):
S>    .put("Src", "./")
S>    .make("install")
S>    .umount("/mnt/ramdisk");
S>

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

_>>Стандартную библиотеку указывать не надо. Дополнительные библиотеки указываются как и везде с помощью команды import. А причём тут это вообще? )
S> А в том, что их указывать то надо по любом. Так, что в худшем случае речь идет от двух строчках, в лучшем со Scripting API одно и тоже.

Ну вот когда этот самый Scripting API кто-то будет реально использовать на практике, то тогда и можно будет о чём-то говорить. )

S>Вот пример использования в 1С

А 1C то тут причём? )

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

_>>Ты хоть сам то читаешь то, на что кидаешь ссылки?
I>Именно. Ты, похоже, даже не понял, что сам же предложил и что тебе ответили
I>Поскольку ты очень плохо читаешь и забываешь контекст, я выделил
I>"Конечно.
I>

Есть такая штука как Connection Pool.

I> Она замечательно решает проблему новых подключений на каждый запрос/группу запросов.
I>

Деражать подключение открытым между запросами ради Prepare абсолютно точно плохая идея.

I>"
I>То есть, речь изначально шла про коннекшн пул ! Ты сам это видишь ?
I>То есть, речь не про удержания подключения вообще, а именно про удержание ради Prepare-Execute.
I>В многопоточной среде на такие фокусы никакого коннекшн пула не хватит.

Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )

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

_>>Так приведи пример хоть одной такой SQL конструкции.
НС>Я же вроде ясно чуть выше написал — ad-hoc типы.

Ну так ты приведёшь хотя бы один пример этой самой "простейщей для SQL конструкции", ради которой "в С++ приходится вставать раком"? ) Или будем считать твои слова пустой болтовнёй? )

_>>Ну а потом наоборот сделаем. Я приведу пример какой-нибудь SQL конструкции (например рекурсивного CTE запроса)
НС>Ну то есть ты увидел у IT про проблемы с CTE, и теперь машешь этим флагом, как будто это не единичный случай, а норма?

И не только про CTE. В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы. Думаю, что если покопаться, то ещё много чего интересного всплывёт. )

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

_>>Да не про то речь. ))) Вот класс Program и функция Main вот прямо в этом твоём коде. Без них можно (пример Ikemefula был без них) или нет?
НС>А при чем тут динамика?

Не знаю причём тут динамика. ) В данной подветке дискуссии меня веселят попытками доказать, что написание скриптов (обычных, а не серверных или встроенных в приложения) на C# (а кто-нибудь вообще слышал про такое?) не менее удобно чем на Питоне. )))

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

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

_>>>Да не про то речь. ))) Вот класс Program и функция Main вот прямо в этом твоём коде. Без них можно (пример Ikemefula был без них) или нет?
НС>>А при чем тут динамика?

_>Не знаю причём тут динамика. ) В данной подветке дискуссии меня веселят попытками доказать, что написание скриптов (обычных, а не серверных или встроенных в приложения) на C# (а кто-нибудь вообще слышал про такое?) не менее удобно чем на Питоне. )))
Ну ты про многое не слышал и не знаешь. Удобно писать на том, что хорошо знаешь, а сделать консоль не проблема.

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

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

_>>>Какое интересно автодополнение ты видишь в данном примере? )
S>> Все методы put,mount итд
S>>

S>>lcd("project")
S>>    .mount("-t tmpfs -o size=500M tmpfs /mnt/ramdisk")
S>>    .mkdir("/mnt/ramdisk/project")
S>>    .cd("/mnt/ramdisk/project"):
S>>    .put("Src", "./")
S>>    .make("install")
S>>    .umount("/mnt/ramdisk");
S>>

_>А, ты про данный пример. Я то про свой вариант на Питоне говорил, где все эти функции являются свободными. А этот вариант даже смешно обсуждать в связи с его убогостью. Ну попробуй добавить туда например for или if и сразу поймёшь это. )))

Linq и where?
_>>>Стандартную библиотеку указывать не надо. Дополнительные библиотеки указываются как и везде с помощью команды import. А причём тут это вообще? )
S>> А в том, что их указывать то надо по любом. Так, что в худшем случае речь идет от двух строчках, в лучшем со Scripting API одно и тоже.

_>Ну вот когда этот самый Scripting API кто-то будет реально использовать на практике, то тогда и можно будет о чём-то говорить. )

Я использую в 1С.
S>>Вот пример использования в 1С

_>А 1C то тут причём? )
В, том что в данном случае она выступает как консоль

Здравствуйте, alex_public, Вы писали:
_>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
Омг. Объясняю на пальцах. Сейчас реализовать работу без connection pool можно только нарочно, поэтому этой возможностью мы пренебрежём.
И вот у нас есть два приложения, делающих одно и то же: регулярно (допустим, в цикле) исполняется один и тот же запрос "Query A", с разными параметрами.
В Виллариба тупо делают Connection.Open.Execute, в Виллабаджо — сначала делается Prepare, а затем внутри цикла Execute.
Цикл, ессно, состоит не только из execute. Как правило, там какая-то дополнительная работа — чтение новых параметров, иногда ещё и отправка результатов удалённому клиенту.
Виллариба полагается на то, что СУБД сама определит, что запрос похож на недавно использованный, и возьмёт готовый план. Почти всегда это именно так.
Виллабаджо не верит СУБД, и блокирует соединение из пула даже тогда, когда само им не пользуется.

Когда у нас крутятся по 20 таких циклов одновременно, то Виллариба использует примерно 10 подключений из пула, а Виллабаджо — 20.
Это если 50% времени цикла занимает общение с СУБД.
Если 20% — то ситуация быстро станет ещё хуже: Виллариба станет использовать примерно 4 соединения, а Виллабаджо — по-прежнему 20.
И так далее.

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

НС>>Я же вроде ясно чуть выше написал — ad-hoc типы.
_>Ну так ты приведёшь хотя бы один пример этой самой "простейщей для SQL конструкции", ради которой "в С++ приходится вставать раком"?

Я жирным выделил. Что то ты даже со второго раза не в состоянии понять что тебе пишут. Опять дурака включаешь?

НС>>Ну то есть ты увидел у IT про проблемы с CTE, и теперь машешь этим флагом, как будто это не единичный случай, а норма?
_>И не только про CTE.

Только.

_> В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы.

Опять бред несешь. Умеют. Проблема с предкомпилированными запросами не в ORM, а в необходимости удерживать соединение. И эта проблема ровно в том же масштабе имеет место быть даже при полностью ручном доступе.
А уж как в твоей голове отсутствие Prepare при компиляции linq запросов превратилось в невозможность использования prepare в ORM в принципе — загадка сие великая есть.

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

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

_>>>Ты хоть сам то читаешь то, на что кидаешь ссылки?
I>>Именно. Ты, похоже, даже не понял, что сам же предложил и что тебе ответили
I>>Поскольку ты очень плохо читаешь и забываешь контекст, я выделил
I>>"Конечно.
I>>

Есть такая штука как Connection Pool.

I>> Она замечательно решает проблему новых подключений на каждый запрос/группу запросов.
I>>

Деражать подключение открытым между запросами ради Prepare абсолютно точно плохая идея.

I>>"
I>>То есть, речь изначально шла про коннекшн пул ! Ты сам это видишь ?
I>>То есть, речь не про удержания подключения вообще, а именно про удержание ради Prepare-Execute.
I>>В многопоточной среде на такие фокусы никакого коннекшн пула не хватит.

_>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил).

Я тебе именно ту часть и процитировал.

>На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее.

Ты похоже даже большие синие буквы прочесть не можешь.

>И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )

1 Все подключения идут через пул. Все, абсолютно все, до тех пор пока ты явно это не запретишь.
2 Prepare-Execute блокирует соединение в конекшн-пуле на бОльший период, нежели обычный запрос.
3 Следствие — ты, фактически, юзаешь гораздо больше соединений, отсюда нагрузка на базу, сеть больше. Это, разумеется, в многопоточном приложении. Если у тебя физический поток ровно один, можешь удерживать соединение ради Prepare-Execure хоть неделями.

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

_>>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
S>Омг. Объясняю на пальцах. Сейчас реализовать работу без connection pool можно только нарочно, поэтому этой возможностью мы пренебрежём.
S>И вот у нас есть два приложения, делающих одно и то же: регулярно (допустим, в цикле) исполняется один и тот же запрос "Query A", с разными параметрами.
S>В Виллариба тупо делают Connection.Open.Execute, в Виллабаджо — сначала делается Prepare, а затем внутри цикла Execute.
S>Цикл, ессно, состоит не только из execute. Как правило, там какая-то дополнительная работа — чтение новых параметров, иногда ещё и отправка результатов удалённому клиенту.
S>Виллариба полагается на то, что СУБД сама определит, что запрос похож на недавно использованный, и возьмёт готовый план. Почти всегда это именно так.
S>Виллабаджо не верит СУБД, и блокирует соединение из пула даже тогда, когда само им не пользуется.

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

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

S>Когда у нас крутятся по 20 таких циклов одновременно, то Виллариба использует примерно 10 подключений из пула, а Виллабаджо — 20.
S>Это если 50% времени цикла занимает общение с СУБД.
S>Если 20% — то ситуация быстро станет ещё хуже: Виллариба станет использовать примерно 4 соединения, а Виллабаджо — по-прежнему 20.
S>И так далее.

1. Ну и? Что такого страшного ты видишь в 20 подключениях? )
2. Если уж очень нервирует (хотя это бред), то ты легко можешь сохранить старую схему работы (с этими виртуальными open/close на каждый запрос). Странно что ты этого не видишь. Достаточно в коде инициализации нового подключения в пуле добавить предкомпиляцию всех статических запросов и всё. Это делается тривиально и в итоге у тебя будет точно такой же код как и раньше. Только при этом СУБД не будет тратить каждый раз усилия на анализ запроса.

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

НС>>>Я же вроде ясно чуть выше написал — ad-hoc типы.
_>>Ну так ты приведёшь хотя бы один пример этой самой "простейщей для SQL конструкции", ради которой "в С++ приходится вставать раком"?
НС>Я жирным выделил. Что то ты даже со второго раза не в состоянии понять что тебе пишут. Опять дурака включаешь?

Ну т.е. примера не будет, правильно? Мдаа, неожидал от тебя, что ты докатишься до подобного уровня... )

_>> В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы.
НС>Опять бред несешь. Умеют. Проблема с предкомпилированными запросами не в ORM, а в необходимости удерживать соединение. И эта проблема ровно в том же масштабе имеет место быть даже при полностью ручном доступе.

Ну IT сказал, что linq2db не умеет. И кому мне верить? )

НС>А уж как в твоей голове отсутствие Prepare при компиляции linq запросов превратилось в невозможность использования prepare в ORM в принципе — загадка сие великая есть.

Это ты снова приписываешь мне какие-то свои домыслы. У меня написано все вполне конкретно и подобного нигде нет.

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

>>И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
I>1 Все подключения идут через пул. Все, абсолютно все, до тех пор пока ты явно это не запретишь.
I>2 Prepare-Execute блокирует соединение в конекшн-пуле на бОльший период, нежели обычный запрос.

Это только при самой тупой реализации в лоб. Хотя в принципе и она будет вполне эффективна.

I>3 Следствие — ты, фактически, юзаешь гораздо больше соединений, отсюда нагрузка на базу, сеть больше. Это, разумеется, в многопоточном приложении. Если у тебя физический поток ровно один, можешь удерживать соединение ради Prepare-Execure хоть неделями.

Откуда нагрузка на базу и сеть больше? )

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

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

>>>И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
I>>1 Все подключения идут через пул. Все, абсолютно все, до тех пор пока ты явно это не запретишь.
I>>2 Prepare-Execute блокирует соединение в конекшн-пуле на бОльший период, нежели обычный запрос.

_>Это только при самой тупой реализации в лоб. Хотя в принципе и она будет вполне эффективна.
Ты забываешь, что в реалиях запросов огромное количество (тысячи и десятки тысяч), в том числе и динамических. Ты все зациклен на поиске по ID. В реалиях же обычно куча динамических запросов

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

НС>>Я жирным выделил. Что то ты даже со второго раза не в состоянии понять что тебе пишут. Опять дурака включаешь?
_>Ну т.е. примера не будет, правильно?

У тебя вообще как с головой? Тебе еще раз написать — "ad-hoc типы"?

_>Ну IT сказал, что linq2db не умеет. И кому мне верить? )

Цитату не затруднит?

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

I>>1 Все подключения идут через пул. Все, абсолютно все, до тех пор пока ты явно это не запретишь.
I>>2 Prepare-Execute блокирует соединение в конекшн-пуле на бОльший период, нежели обычный запрос.

_>Это только при самой тупой реализации в лоб. Хотя в принципе и она будет вполне эффективна.

См пример Синклера про Виллариба и Виллабаджо.

I>>3 Следствие — ты, фактически, юзаешь гораздо больше соединений, отсюда нагрузка на базу, сеть больше. Это, разумеется, в многопоточном приложении. Если у тебя физический поток ровно один, можешь удерживать соединение ради Prepare-Execure хоть неделями.

_>Откуда нагрузка на базу и сеть больше? )

Соединений больше, это же очевидно.

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

_>>> В данной дискуссии выяснилось что данные ORM почему-то не умеют и предкомпилированные в СУБД запросы.
НС>>Опять бред несешь. Умеют. Проблема с предкомпилированными запросами не в ORM, а в необходимости удерживать соединение. И эта проблема ровно в том же масштабе имеет место быть даже при полностью ручном доступе.

_>Ну IT сказал, что linq2db не умеет. И кому мне верить? )

Ты или юродствуешь, или не понял, чего же тебе IT сказал:

Видимо мы о чём-то разном.

Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента.

Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея.

OR/M не делает Prepare, именно потому, что этот Prepare очень противоестественным образом использует Connection Pool. Собственно, это совсем не значит, что OR/M Не может делать Prepare. При желании, это легко допиливается.
Реально такой фокус даже в рукопашных сценариях с прямым доступом к базе мало кто использует.