Сообщение Re[91]: Тормознутость и кривость linq от 23.05.2016 7:13
Изменено 23.05.2016 7:15 Serginio1
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
S>> Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.
_>Правильно понимаешь. )
S>>Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?
_>Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))
S>> Ты на ассемблере еще не программируешь?
_>Бывает изредка, а что? )
Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку
_>Здравствуйте, Serginio1, Вы писали:
_>>>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
S>> Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.
_>Правильно понимаешь. )
S>>Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?
_>Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))
S>> Ты на ассемблере еще не программируешь?
_>Бывает изредка, а что? )
Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку
Re[91]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
S>> Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.
_>Правильно понимаешь. )
Ну и держать десятки тысяч SqlCommand держать как то не комильфо. А в нормальных базах таких запросов это обычное дело. Кроме того столь кож еще и динамических
S>>Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?
_>Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))
Атавизмы встречаются везде.
S>> Ты на ассемблере еще не программируешь?
_>Бывает изредка, а что? )
Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку
_>Здравствуйте, Serginio1, Вы писали:
_>>>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
S>> Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.
_>Правильно понимаешь. )
Ну и держать десятки тысяч SqlCommand держать как то не комильфо. А в нормальных базах таких запросов это обычное дело. Кроме того столь кож еще и динамических
S>>Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?
_>Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))
Атавизмы встречаются везде.
S>> Ты на ассемблере еще не программируешь?
_>Бывает изредка, а что? )
Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку