parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Re: повторное использование запросов и не только

Безымянный 17.04.2003 23:55

Всю работу с запросами можно переложить на драйвер, да и не должен парсер этим заниматься. Навскидку, повторное использование запросов может выглядеть так:

$id[123]
$name[
^string:sql{
prepared select NAME from TABLE where ID=:id;
id=$id
}
]

Здесь используется примерно та же форма, в которой препарированные запросы передаются на сервер: в теле запроса стоят декларации параметров, фактические значения которых указываются отдельно (в данном случае после запроса). Запрос препарится один раз, после чего при последующем выполнении этого запроса (уже с другими параметрами) драйвер по неизменному телу может узнать этот запрос и иcпользовать готовый хэндл, подставив новые значения параметров. Ключевое слово prepared в данном случае указывает, что хэндл запроса после первого выполнения должен быть помещен в кэш. Можно обойтись и без специального ключевого слова, просто кэшировать все запросы, написанные в такой нотации (повторюсь, кэшировать не результат выполнения запроса, а хэндл запроса после prepare).
В этом случае простота парсера отнюдь не пострадает. Да и простота, кстати, не так проста - "простой" парсер имеет крайне сложный, неочевидный и противоестественный синтаксис. Который, тем не менее, оборачивается удобством при разработке, поскольку оптимизирован для решения конкретной задачи, вовсе даже не простой. Я предлагаю не усложнение, а оптимизацию работы с БД - а это позволит решать большие задачи меньшими средствами. То есть, повторюсь, максимально использовать преимущества конкретного сервера средствами конкретного драйвера. Поддержка со стороны парсера требуется минимальная, всего лишь расширение интерфейса services парой функций: permanent_malloc и permanent_free.
Поясню, почему использование препарированных запросов считается хорошим тоном и почему я так на нем настаиваю. При prepare запроса сервер:
- анализирует синтаксис запроса и определяет используемые объекты БД.
- проверяет полномочия пользователя на все используемые объекты. Это означает большое количество выборок из служебных таблиц, при этом также проверяются полномочия на все зависимые объекты, которых может быть большое количество (особенно если это выборка из процедуры, которая обращается к куче таблиц).
- выбирает типы данных для входных и выходных параметров, на клиенте создаются структуры для хранения выходных параметров.
То есть, выполнение одного простого запроса порождает кучу неявных запросов к служебным таблицам. При использовании препарированных запросов все эти операции опускаются.

Ответ на пред. пост: под использованием ХП, видимо, понимается написание процедуры с большим количеством выходных параметров, которая будет сразу делать все нужные странице выборки? Попробую.