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

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

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

Гм, Синклера учить пользоваться SQL — это надо еще додуматься.

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

_>Вообще то дело совсем не в том, что при предкомпилированных запросах будет однозначное использование готового плана. Дело во времени требуемом СУБД для анализа поступившего запроса и выяснения находится ли в кэше готовый план для него или нет.
_>1. Ну и? Что такого страшного ты видишь в 20 подключениях? )
Например, SQL Server по умолчанию резервирует на каждое подключение 1MB кэша. Поэтому 1000 одновременных подключений сожрёт уже целый гигабайт. В 32х разрядах это было вообще убийством; в 64х это просадит производительность.

_>2. Если уж очень нервирует (хотя это бред), то ты легко можешь сохранить старую схему работы (с этими виртуальными open/close на каждый запрос). Странно что ты этого не видишь. Достаточно в коде инициализации нового подключения в пуле добавить предкомпиляцию всех статических запросов и всё.
Можно кусочек кода в студию? А то у меня складывается впечатление, что кто-то из нас не понимает принципов работы prepared statements.

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

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

Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.
Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?
Ты на ассемблере еще не программируешь?

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

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

Ну т.е. делать предкомпилированные запросы в linq2db и т.п. ORM было глупо. Я правильно понял эту твою мысль? )))

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

_>>Ну т.е. примера не будет, правильно?
НС>У тебя вообще как с головой? Тебе еще раз написать — "ad-hoc типы"?

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

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

http://rsdn.ru/forum/flame.comp/6434532.1

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

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

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

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

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

_>>Вообще то дело совсем не в том, что при предкомпилированных запросах будет однозначное использование готового плана. Дело во времени требуемом СУБД для анализа поступившего запроса и выяснения находится ли в кэше готовый план для него или нет.
_>>1. Ну и? Что такого страшного ты видишь в 20 подключениях? )
S>Например, SQL Server по умолчанию резервирует на каждое подключение 1MB кэша. Поэтому 1000 одновременных подключений сожрёт уже целый гигабайт. В 32х разрядах это было вообще убийством; в 64х это просадит производительность.

О, а откуда у нас тут резко взялась 1000 подключений то? ) У нас шла речь только о 20...

_>>2. Если уж очень нервирует (хотя это бред), то ты легко можешь сохранить старую схему работы (с этими виртуальными open/close на каждый запрос). Странно что ты этого не видишь. Достаточно в коде инициализации нового подключения в пуле добавить предкомпиляцию всех статических запросов и всё.
S>Можно кусочек кода в студию? А то у меня складывается впечатление, что кто-то из нас не понимает принципов работы prepared statements.

Да банально такое реализуется. Просто делаешь пул не из некого SqlConnection, а из чего-то вроде:

struct MySqlConnection: public SqlConnection{
    MySqlConnection()
    {
        stmt1=Prepare("...");
        stmt2=Prepare("...");
    }
    SqlStatement stmt1;
    SqlStatement stmt2;
    //...
};

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

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

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

Правильно понимаешь. )

S>Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?

Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))

S> Ты на ассемблере еще не программируешь?

Бывает изредка, а что? )

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

_>О, а откуда у нас тут резко взялась 1000 подключений то? ) У нас шла речь только о 20...
Это был пример. При росте нагрузки будет расти и количество запросов — следовательно, и количество подключений.

_>Да банально такое реализуется. Просто делаешь пул не из некого SqlConnection, а из чего-то вроде:
_>

_>struct MySqlConnection: public SqlConnection{
_>    MySqlConnection()
_>    {
_>        stmt1=Prepare("...");
_>        stmt2=Prepare("...");
_>    }
_>    SqlStatement stmt1;
_>    SqlStatement stmt2;
_>    //...
_>};
_>

_>Ну это так, схематически, но думаю идея очевидна.
а, то есть нужно проанализировать код, и заменить все обращения к Prepare на обращения к stmt1/stmt2/etc?
Выглядит опасненько. Кроме того, я подозреваю, что сами prepared statements таки тоже создают ненулевую нагрузку на сервер — и если мы будем держать по 1000 statements на каждое подключение, то можем на это нарваться.

Однако это всё нужно только если очень захочется сохранить старую никчемную структуру с пулом. В большинстве случаев схема с фиксированными подключениями будет эффективнее. В том числе и с учётом нюансов работы кэша процессора (разделения между ядрами).
.
Вы порете феноменальную чушь. Схема с фиксированными подключениями в большинстве случаев менее эффективна, иначе бы все использовали именно её.

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

_>>>Откуда нагрузка на базу и сеть больше? )
I>>Соединений больше, это же очевидно.

_>И что, что соединений больше? ) По твоему из-за этого объём передаваемых данных в единицу времени станет больше? )

Тебе много раз отвечали на этот вопрос. Ты предпочитаешь юродствовать и передергивать.

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

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

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

_>Ну т.е. делать предкомпилированные запросы в linq2db и т.п. ORM было глупо. Я правильно понял эту твою мысль? )))
Для динамических ты просто не сделаешь компиляцию. Смысл в том, что может сменится провайдер (SQL,Oracl,PostgreSQL ) поэтому компиляция запросов должна быть после соединения с БД.
Ты теряешь время только на компиляцию при подключении.
Для нединамических запросы компилируются и используется кэш.

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

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

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

_>Правильно понимаешь. )
Ну и держать десятки тысяч SqlCommand держать как то не комильфо. А в нормальных базах таких запросов это обычное дело. Кроме того столь кож еще и динамических
S>>Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?

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

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

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

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

_>Ну т.е. делать предкомпилированные запросы в linq2db и т.п. ORM было глупо. Я правильно понял эту твою мысль? )))

Ты делаешь выводы на основе частного случая — запросах по ID.
Предкомпиляция и prepare дают совершенно разный по масштабу профит. Кроме того, у БД есть кеширование планов запроса.
Для твоей схемt нужно замерять второе относительно третьего в реальных сценариях, то есть, сложных и разных динамических запросах.

Ну и оптимизации не аддитивны, пора бы уже понять.

И до кучи — твоя гениальная схемка уже сто лет как известна. Как думаешь, почему её поголовно не применяют, раз она такая классная ?

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

_>>О, а откуда у нас тут резко взялась 1000 подключений то? ) У нас шла речь только о 20...
S>Это был пример. При росте нагрузки будет расти и количество запросов — следовательно, и количество подключений.

Ога, в ответ на вопрос "чем страшны 20 подключений?" ответить "нуу при 1000 подключений у нас...". Хороший такой пример. ))) Пример определённых "навыков" общения. )

Ну и в нормальных системах количество подключений естественно пропорционально совсем не количеству запросов, а количеству параллельных потоков, которое в свою очередь делают пропорциональным числу ядер процессора. Это если у нас нормальная система, а не что-то вроде Apache с mod_php.

_>>Да банально такое реализуется. Просто делаешь пул не из некого SqlConnection, а из чего-то вроде:
_>>Ну это так, схематически, но думаю идея очевидна.
S>а, то есть нужно проанализировать код, и заменить все обращения к Prepare на обращения к stmt1/stmt2/etc?
S>Выглядит опасненько.Кроме того, я подозреваю, что сами prepared statements таки тоже создают ненулевую нагрузку на сервер — и если мы будем держать по 1000 statements на каждое подключение, то можем на это нарваться.

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

S>Однако это всё нужно только если очень захочется сохранить старую никчемную структуру с пулом. В большинстве случаев схема с фиксированными подключениями будет эффективнее. В том числе и с учётом нюансов работы кэша процессора (разделения между ядрами).
S>.
S>Вы порете феноменальную чушь. Схема с фиксированными подключениями в большинстве случаев менее эффективна, иначе бы все использовали именно её.

Аргументированно. )))

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

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

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

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

S>>>Ты забываешь, что в реалиях запросов огромное количество (тысячи и десятки тысяч), в том числе и динамических. Ты все зациклен на поиске по ID. В реалиях же обычно куча динамических запросов
_>>Ну т.е. делать предкомпилированные запросы в linq2db и т.п. ORM было глупо. Я правильно понял эту твою мысль? )))
S> Для динамических ты просто не сделаешь компиляцию. Смысл в том, что может сменится провайдер (SQL,Oracl,PostgreSQL ) поэтому компиляция запросов должна быть после соединения с БД.
S>Ты теряешь время только на компиляцию при подключении.
S>Для нединамических запросы компилируются и используется кэш.

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

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

_>>Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))
S> Атавизмы встречаются везде.



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

Во многих задачах по другому просто нельзя.

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

I>>>>Соединений больше, это же очевидно.
_>>>И что, что соединений больше? ) По твоему из-за этого объём передаваемых данных в единицу времени станет больше? )
I>>Тебе много раз отвечали на этот вопрос. Ты предпочитаешь юродствовать и передергивать.

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

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

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

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

S>>>>Ты забываешь, что в реалиях запросов огромное количество (тысячи и десятки тысяч), в том числе и динамических. Ты все зациклен на поиске по ID. В реалиях же обычно куча динамических запросов
_>>>Ну т.е. делать предкомпилированные запросы в linq2db и т.п. ORM было глупо. Я правильно понял эту твою мысль? )))
S>> Для динамических ты просто не сделаешь компиляцию. Смысл в том, что может сменится провайдер (SQL,Oracl,PostgreSQL ) поэтому компиляция запросов должна быть после соединения с БД.
S>>Ты теряешь время только на компиляцию при подключении.
S>>Для нединамических запросы компилируются и используется кэш.

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

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

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

_>>>Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))
S>> Атавизмы встречаются везде.

_>

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

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