Исходное сообщение
"bind" Отправлено Pashugan, 18-Июн-10 14:52
>Вы в корне не правы (или правы в некотором частном случае)! >может быть для MySQL это и правда, но приличные СУБД (в частности >Oracle) _кешируют_ запросы после парсинга. в итоге запрос повторно разбирать не >нужно! >собственно число запросов в приложении конечно и при достаточном обьеме кеша у >СУБД это неплого ускоряет работу. Так ли в корне он неправ? Помимо времени на компиляцию запроса есть ещё фактор двойной передачи данных - запроса и параметров. Скорее всего, вычисление ключа кеша осуществляется на сервере, а значит текст запроса всё равно нужно сначала передать на сервер. Так что продолжать спорить считаю бессмысленным, и если у Вас есть под рукой Oracle с быстрым надёжным каналом до него, буду рад увидеть результаты тестов.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>Вы в корне не правы (или правы в некотором частном случае)! >>может быть для MySQL это и правда, но приличные СУБД (в частности >>Oracle) _кешируют_ запросы после парсинга. в итоге запрос повторно разбирать не >>нужно! >>собственно число запросов в приложении конечно и при достаточном обьеме кеша у >>СУБД это неплого ускоряет работу. > Так ли в корне он неправ? Помимо времени на компиляцию запроса есть > ещё фактор двойной передачи данных - запроса и параметров. Скорее всего, > вычисление ключа кеша осуществляется на сервере, а значит текст запроса всё > равно нужно сначала передать на сервер. Так что продолжать спорить считаю > бессмысленным, и если у Вас есть под рукой Oracle с быстрым > надёжным каналом до него, буду рад увидеть результаты тестов.
	Введите код, изображенный на картинке: