для СУБД mSQL і для СУБД MySQL – аналогічні. А так як інтерфейс СУБД MySQL був розроблений як інтерфейс, який подібний інтерфейсу СУБД mSQL, потрібно було пристосувати драйвер СУБД mSQL для роботи з СУБД MySQL.
Архітектура DBI-інтерфейсу дозволяє створювати програми у відносно традиційному жанрі. При написанні сценарію DBI використовується стандартний набір викликів.
Рисунок 2.2 – Архітектура інтерфейсу 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 i драйвер.
Однак це все теорія. На практиці проти переносимості сценаріїв DBI працює два фактори.
Різні механізми баз даних працюють з різними діалектами мови SQL. І цілком можливо, що SQL-запит, написаний для однієї бази даних, не буде "зрозумілим" іншій. Якщо притримуватись традиційного стилю у написанні SQL-запитів, то існує велика ймовірність, що переносимість буде забезпечена. Але якщо відповідний діалект SQL залежить від механізму бази даних, то і сценарії також будуть залежати від нього.
Модулі драйверів баз даних мають інформацію, яка залежить від конкретної бази даних. Це дозволяє розробникам ефективно використовувати особливості конкретної бази даних. Наприклад, драйвер СУБД MySQL забезпечує метод доступу до стовпців в результатах запиту, таких як максимальна довжина кожного стовпця, чи є стовпці числовими і.т.д. Відомо, що ці можливості мають який-небудь аналог в інших базах даних. Такі можливості драйверів є вагомою перепоною самій ідеології переносимості. Використовуючи такі розробки сценарію, розробник повинен чітко усвідомлювати, що він втрачає можливість використовувати цей сценарій при роботі з іншими СУБД.
Не дивлячись на потенціал цих двох факторів при створенні сценаріїв, які залежать від СУБД, механізм DBI забезпечення доступу до бази даних абстрактного типу є вагомим засобом досягнення переносимості.
Інтерфейс РНР АРІ. Як і мова Perl, мова РНР є мовою для створення сценаріїв, але мова РНР створювалась швидше не як мова універсального призначення, а як мова, основною задачею якої є створення Web-програм. Інтерфейс РНР АРІ використовується в першу чергу в якості засобу інтегрування сценаріїв у Web-сторінки. Це спрощує задачу розробникам Web-вузлів по створенню динамічних Web-сторінок. Сам обмін відбувається наступним чином: клієнтський браузер посилає запит про РНР-сторінку на Web-сервер, РНР виконує будь-який найдений на сторінці сценарій і заміщує його відповідним результатом. Цей результат відсилається назад браузеру. Це дозволяє сторінці, яка реально відображається у вікні браузера, змінюватись в залежності від обставин, при яких вона була викликана. Наприклад, включення такого РНР-сценарію в тіло Web-сторінки призведе до відображення результатів запиту до бази даних.
<HTML>
<HEAD>
<Title>Net.Search Інформаційно-пошукова система</Title>
</HEAD>
<BODY>
<?php
$link=@mysql_pconnect("localhost","ODBC","") or
die("Неможливо встановити з'єднання з MySQL");
mysql_select_db("sites") or
die("Не вдалося підключитися до бази даних");
$query="Select urls.url_address from urls,key_words
where key_words.key_word='C++ Builder'
and urls.site_id=key_words.site_id";
$result=mysql_query($query)
or
die("Неможливо виконати запит");
print("<p align='center'p>");
print("<TABLE border='1'>\n");
while($row=mysql_fetch_row($result))
{
print("<TR>\n");
for($i=0;$i<mysql_num_fields($result); $i++)
{
printf("<TD>%s</TD>\n",htmlspecialchars($row[$i]));
}
print("</TR>\n");
}
mysql_free_result($result);
print("</TABLE>\n");
?>
</BODY></HTML>
В результаті обробки інтерпретатором цього сценарію сформована Web-сторінка мала наступний вигляд:
<HTML><HEAD>
<Title>Net.Search Інформаційно-пошукова система</Title>
</HEAD>
<BODY>
<p align='center'p><TABLE border='1'>
<TR><TD>http://www.borland.com</TD></TR>
<TR><TD>http://www.cppbuilder.com</TD></TR>
<TR><TD>http://www.microsoft.com</TD></TR>
<TR><TD>http://www.delphi.com</TD></TR></TABLE>
</BODY></HTML>
Як видно з наведених вище текстів опису Web-сторінок, сценарії РНР виглядають як звичайні HTML-сторінки, які розташовуються всередині маркерів <?php i ?>. Сторінка може мати декілька сценаріїв. Це забезпечує достатньо гнучкий підхід до розробки сценаріїв. Наприклад можна створити звичайну HTML-сторінку в яку згодом буде включений сценарій.
Мові РНР не потрібно "робити зусиль" для уніфікації інтерфейсу з різними базами даних подібно інтерфейсу DBI. Навпаки інтерфейс до кожної бази даних представляє собою інтерфейс з відповідною бібліотекою С, яка здійснює АРІ-інтерфейс низького рівня з будь-якою базою даних. Наприклад, імена функцій мови РНР, які призначені для доступу до бази даних MySQL із сценаріїв РНР, дуже подібні на імена функцій клієнтської бібліотеки мови С.
2.3.2 Вибір АРІ-інтерфейсу
В процесі вибору типу інтерфейсу АРІ враховувалось багато факторів.
Середовище, в якому буде виконуватись задача. Контекст, в якому буде виконуватись програма.
Продуктивність. Яка ефективність програм, написаних із застосуванням того чи іншого інтерфейсу.
Простота розробки. Наскільки зручно працювати з інтерфейсом і його мовою при створенні програм.
Переносимість. Чи будуть використовуватися програми для роботи з іншим базами даних [2].
Середовище виконання. Розробник програми завжди знає, в якому середовищі буде працювати програма. Наприклад, це може бути програма генерації звітів. В якості іншого прикладу можна навести програму, яка буде запускатися Web-сервером. Така програма повинна "вміти" "витягувати" інформацію специфічного типу зі свого робочого середовища. Яким браузером користується клієнт? Які параметри заносяться у форму списку розсилки при запиті на підписку? Чи вводить клієнт правильний пароль для того, щоб дістати доступ до інформації про персонал?
Всі мови АРІ володіють різними