Информация об изменениях

Сообщение 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>> Ты на ассемблере еще не программируешь?


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

Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку
Re[91]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:

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


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

S>> Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.

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

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

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

Атавизмы встречаются везде.
S>> Ты на ассемблере еще не программируешь?

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

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