Уровень DBD (драйверов баз данных). Поддержка различных механизмов баз данных производится именно на этом уровне. Он реализован с помощью драйверов, которые настроены на механизм определенной базы данных

Уровень приложения

Сценарий Perl

$dbh = DBI->connect ( DBIimSQL:. ...или

$dbh = DBI->connect( DBI:mysqr. ...или ..

$dbh = DBI->connect ( DBIiPg:... );

Уровень интерфейса базы данных

Уровень драйверов базы данных

Интерпретатор Perl

Рис. 5.1. Архитектура интерфейса DBI

Поддержка интерфейса DBI MySQL обеспечивается модулем Msql-Mysql-modules. Этот модуль работает на уровне драйверов базы данных. Как явствует из названия модуля и рис. 5.L драйвер может обеспечивать поддержку нескольких СУБД. Модуль Msql-Mysql-modules был первоначально создан для работы с СУБД mSQL, а затем его функциональность была расширена до СУБД MySQL, поэтому API-интерфейс для СУБД mSQL и для СУБД MySQL - аналогичны. А вследствие того, что интерфейс СУБД MySQL был разработан как интерфейс, подобный интерфейсу СУБД mSQL, имело смысл и сам драйвер СУБД mSQL (который используется API-интерфейсом СУБД mSQL) приспособить для работы с СУБД MySQL.

Архитектура DBI-интерфейса позволяет создавать приложения в относительно традиционной манере. При написании сценария DBI используется стандартный набор вызовов. Уровень DBI вызывает соответствующий драйвер уровня DBD для обработки запросов, а уже драйвер возлагает на себя рещение всех проблем, связанных с соединением с сервером определенной базы данных. Данные, полученные от сервера, возвращаются обратно на уровень DBD и дальше через уровень DBI данные

возвращаются приложению. Целостность данных не зависит от того, из какой базы данных они были получены.

В результате имеем интерфейс, скрывающий от разработчика приложения различия между механизмами баз данных, но работающий с широким диапазоном баз данных. Настолько большим, насколько хватает драйверов. Интерфейс DBI обеспечивает надежный интерфейс клиентского рабочего места и улучшает переносимость, которая позволяет осуществлять доступ к базам данных в унифицированном формате.

Единственная особенность, отражающая специфику базы данных, проявляется в момент открытия базы данных. В момент установки связи необходимо указывать, с помощью какого драйвера она будет осуществляться. Например, при работе с СУБД MySQL подключение необходимо производить следующим образом:

$dbh = DBI -> connect ( DBI:mysql:... );

Для работы с СУБД Postgres или mSQL подключение необходимо производить командой:

$dbh = DBI -> connect ( DBI:Pg:... ); $dbh = DBI -> connect ( DBI:mSQL:... );

После подключения какого-либо упоминания о драйвере не нужно. Вся обработка специфических нюансов конкретной базы данных полностью возложена на интерфейс DBI и драйвер.

Однако это все теория. На практике против переносимости сценариев DBI работает два фактора.

Различные механизмы баз данных работают с различными диалектами языка SQL. И совершенно вероятно, что SQL-запрос, написанный для одной базы данных, не будет понятен другой. Если вы придерживаетесь традиционного стиля в написании SQL-запросов, то существует высокий процент вероятности, что переносимость будет обеспечена. Но если определенный диалект SQL зависит от механизма базы данных, то сценарии тоже будут зависеть от него. Например, сценарий, использующий оператор SHOW TABLES и присущий только диалекту языка SQL MySQL, не будет работать с другими базами данных.

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

осознавать, что он теряет возможность использовать этот сценарий в работе с другими СУБД.

Несмотря на потенциал этих двух факторов при создании сценариев, зависимых от СУБД, механизм DBI обеспечения доступа к базе данных абстрактного типа является существенным средством достижения переносимости. Это уже задача разработчика, рещать, какие преимущества вы хотите извлечь из такого механизма.

Интерфейс РНР API

Как и язык Perl, язык РНР является языком язык создания сценариев, но язык РНР создавался скорее не как язык общего назначения, а как язык, основной задачей которого является создание Web-приложений. Интерфейс РНР API используется в первую очередь в качестве средства включения сценариев в Web-страницы. Это упрощает задачу разработчиков Web-узлов по созданию динамических Web-страниц. Сам обмен происходит следующим образом: клиентский броузер посылает запрос о РНР-странице на Web-сервер, РНР выполняет любой найденный на странице сценарий и замещает его полученным результатом. Этот результат посылается обратно броузеру. Это позволяет странице, которая реально отображается в экране броузера, изменяться в зависимости от обстоятельств, при которых она была вызвана. Например, включение такого короткого РНР-сценария в тело Web-страницы приведет к отображению IP-адреса узла, запросившего страницу:

<?php echo SREMOTE ABDR; ?>

Вот менее тривиальная и более интересная программа, которая будет давать поминутную информацию о посетителях на основании информации, содержащейся в базе данных. Следующий пример демонстрирует простой сценарий, которым можно воспользоваться на Web-узле Исторической Лиги . Этот сценарий генерирует запрос, определяющий текущее количество действительных членов, и сообщает его посетителю. (Если происходит ошибка, сценарий ничего не сообщает.)

<HTML> <HEAD>

<Т1ТЬЕ>Историческая Лига CII1A</TITLE>

</HEAD>

<BODY>

<Р>Добро пожаловать на Web-узел Исторической Лиги . <?php

Slink = @mysql pconnect ( pit.viper.snake.net , paul , secret )

or exit(); mysql select db( samp db )

Тем не менее, автор продемонстрирует в главе 7, что вполне возможно избегать конструкций, характерных только для конкретной СУБД MySQL. Так что выбор целиком лежит на совести разработчика - решать использовать ему такие конструкции в своей работе или нет.