Не пытайтесь использовать шаблон для ключевых слов. Это не даст результата, так как значения маркеров автоматически обрабатываются методом quote (). В таком случае ключевое слово в запросе будет взято в кавычки, и запрос не сработает из-за синтаксической ошибки.

Иногда от использования маркеров можно получить еще один выигрыш. В некоторых базах данных по мере планирования эффективного выполнения запросов кэшируют уже готовые к выполнению готовые запросы. Таким образом, если такой же запрос будет получен повторно, он может быть использован снова, минуя этап генерации плана выполнения. Кэширование запросов очень эффективно при обработке сложных запросов SELECT, так как генерация хорошего плана выполнения таких запросов может занимать много времени. Маркеры дают больше шансов для создания универсальных запросов и, соответственно, для попадания их в кэш-память. В случае с нашей СУБД MySQL шаблоны не дают такого выифыша производительности, прежде всего потому, что СУБД MySQL не кэширует запросы. Тем не менее, не надо бояться использования маркеров. Ведь может случиться так, что ваш сценарий, реализующий интерфейс DBL будет работать с другой СУБД, которая как раз и использует механизм кэширования запросов. И ваш сценарий с маркерами будет работать эффективней.

Маркеры позволяют подставлять значения в запросы непосредственно во время выполнения запроса. Другими словами, они позволяют парамет-ризировать запрос. Интерфейс DBI также позволяет осуществлять соответствующую операцию вывода, которая называется связыванием параметров . Эта операция позволяет параметризировать вывод и автоматически присваивать выбранные значения столбцов прямо переменным, минуя этап принудительного присвоения.

Предположим, что у нас есть запрос на выборку имен членов из таблицы member. Можно задать интерфейсу DBI режим, при котором будут назначаться значения выбранных столбцов переменным Perl. При выборке строки переменные будут автоматически инициализированы соответствующими значениями столбцов. Вот пример, показывающий, каким образом можно связать столбцы с переменным, а затем получить доступ к ним в цикле выборки;

$sth = $dbh->prepare (qq{

SELECT last name, first name, suffix FROM member

ORDER BY last name, first name

$sth->execute () ; $sth->bind col (1, \$last name); Ssth->bind col (2, \$first name); $sth->bind col (3, \$suffix);

print $last name, $first name, $suffix\n while $sth->fetch;

Каждый вызов метода bind col () призван определить номер столбца и ссылку на переменную, которая ассоциируется с этим столбцом. Нумерация столбцов начинается с 1. Метод bindcolO должен вызываться после отработки метода execute ().

Сушествует и другой способ, при котором используется только один вызов метода bind col(). В этом случае методу передаются ссылки на переменные:

$sth = $dbh->prepare (qq{

SELECT last name, first name, suffix FROM member

ORDER BY last name, first name

$sth->execute {);

$sth->bind columns {\$last name, \$first name, \$suffix); print $last name, $first name, $suffix\n while $sth->fetch;

Определение параметров соединения

Наиболее простой способ установки параметров соединения - определение всех параметров в момент выполнения метода connect ():

$data source = DBI: mysql :db name:host name ; $dbh->connect {$data source, user name, password) ;

При установке параметров соединения интерфейс DBI делает сле-дуюшее.

Переменная установки среды DBIDSN используется в случае, если источник данных не определен или его значение не является пустой строкой. Переменные DBI 0SER и DBI PASS используются, если не определень! имя пользователя и пароль (но в этом случае они не могут быть представлены пустой строкой). Работая под ОС Windows, в случае неопределенности имени пользователя используется переменная USER.

По умолчанию принимается имя узла localhost.

Если имя пользователя имеет значение undef или пустая строка , по умолчанию используется регистрационное имя UNIX. Под ОС Windows имя пользователя имеет значение ODBC.

Если пароль имеет значение undef или пустая строка , пароль не передается.

Опции можно указывать, добавив их в начало выражения и предварив двоеточием. Например, для определения имени конфигурационного файла можно указать опцию mysql read def ault f Не:

$data source =

DBI:mysql:samp db;mysql read default file=/u/paul/.my.cnf ;

При выполнении сценария открывается файл, содержащий параметры соединения. Предположим, что файл /u/paul/.ту. cnf содержит:

[client]

host=pit-viper.snake.net

user=paul

password=secret

После этого метод connect () попытается подключиться к серверу MySQL, расположенному на узле pit-viper.snake.net. При успешном соединении будет подключен пользователь paul с паролем secret. Чтобы дать возможность пользоваться вашим сценариемлюбому пользователю, можно задать источник данных следующим образом:

$data source =

DBI:mysql:samp db;mysql read default file=$ENV{HOME}/.my.cnf ;

Здесь переменная $ENV{HOME} содержит путь к корневому каталогу пользователя, запустившего сценарий. Таким образом, имена узла и пользователя и его пароль, используемые сценарием, будут взяты из конфигурационного файла каждого пользователя. Для сценария, написанного таким образом, необходимость хранить в своем теле параметры соединения отпадает.

Для определения групп можно воспользоваться опцией mYsql read default group. Она автоматизирует чтение конфигурационного файла .my.cnf данного пользователя и позволяет производить чтение дополнительной группы в дополнение к группе [client]. Например, если у вас имеются опции, которые присуши только для ваших сценариев, работающих с интерфейсом DBL их можно перечислить в фуппе [dbi] и указать еще один источник данных:

$data source =

DBI:mysql:samp db;mysql read default group=dbi ;

Работа с опциями mysql read default file и mysql read default group возможна только для версии MySQL 3.22. Ю или выше и драйверов DBD::mysql L2L06 или выше. Более подробную информацию на эту тему можно найти в приложении Ж, Профаммный интерфейс DBI языка написания сценариев Perl . Детальную информацию на предмет формата конфигурационных файлов MySQL можно найти в приложении Д, Профаммы MySQL .

Использование конфигурационных файлов совсем не освобождает вас от необходимости объявления парамефов конфигурации при вызове метода connect () (например, в сценарии, подключающем определенного пользователя). Любые имена узлов, пользователей и паролей, указанные при вызове метода connect () явным образом, имеют более высокий приоритет, чем парамефЫ, указанные в конфигурационном файле. Например, необходимо, чтобы сценарий анализировал опции - -host, - -user и - -password, указанные в командной сфоке, и отдавал приоритет этим значениям перед значениями, указанными в конфигурационном файле. Это достаточно традиционное поведение стандартного пользователя СУБД MySQL. Таким образом, создаваемые вами сценарии DBI должны учитывать такое положение вещей.