оказаться, что ваши приложения не могут ни удовлетворить ваши потребности, ни 
приспособиться к изменяющимся обстоятельствам. В нашем обзоре программирования 
баз данных мы коснемся таких сложных тем, как понятие об обычной двухзвенной 
архитектуре, соответствие между объектами и реляцион-ностью и более новой 
трехзвенной архитектуре клиент/сервер.
Архитектура клиент/сервер
В упрощенном виде архитектура клиент/сервер предполагает разделение 
происходящей в приложении обработки на две или более логически различные части. 
До сих пор в этой книге мы обсуждали базы данных так, будто они существуют в 
некоем безвоздушном пространстве. Однако они выполняют свое предназначение 
только тогда, когда используются какими-либо приложениями. Упрощая, можно 
сказать, Что база данных составляет одну часть архитектуры клиент/сервер. База 
данных является «сервером», а всякое использующее ее приложение является 
«клиентом». Часто клиент и сервер расположены на разных машинах; в большинстве 
случаев приложение клиента является дружественным интерфейсом к базе данных. На 
рис. 8-1 графически представлена простая система клиент/сервер.
Возможно, вы уже встречали в Интернет такую структуру. По сути, мы будем 
обращаться к определенной задаче приложений клиент/сервер для Интернет на 
протяжении всей книги. К примеру, WWW является гигантским приложением типа 
клиент/сервер, в котором Web-броузер является клиентом, а Web-сервер- сервером. 
В этом сценарии сервер является не сервером реляционных баз данных, а 
специализированным файл-сервером. Важнейшим свойством сервера является то, что 
он предоставляет данные клиенту в определенном формате.

Рис. 8-1. Архитектура клиент/сервер
При создании приложения для работы с базой данных прежде всего необходимо иметь 
возможность связать клиента с базой данных. Поставщики баз данных предпочитают 
скрывать от разработчиков основополагающие механизмы связи посредством API, 
ориентированных на конкретный язык. Когда вы создаете приложение для работы с 
базой данных, то используете специальные библиотеки, которые транслируют ваши 
запросы в пакеты TCP/IP, передающиеся по сети к серверу базы данных.
Внешний вид этих API для доступа к базам данных различен и зависит от языка 
программирования, а во многих случаях - и от самой базы данных. Поскольку API 
для MySQL намеренно разрабатывались так, чтобы иметь сходство с mSQL, у всех 
API, которые вы найдете в этой книге, различия минимальны.
Обработка данных
В части I «Введение в MySQL и mSQL» мы дали понятия управления транзакциями и 
результирующего набора. Приложение для работы с базой данных — всего лишь 
инструмент для управления транзакциями и обработки результирующих наборов. 
Например, если ваше приложение является адресной книгой, то обработка 
результирующих наборов заключается в том, чтобы извлечь из таблицы все строки и 
показать их пользователю. Управление транзакциями просто сводится к тому, чтобы 
изменения в таблицах address и person производились как единое целое.
Мы уже упоминали, что в MySQL и mSQL нет поддержки транзакций. Всякое изменение 
в базе данных совершается автоматически, когда вы его запрашиваете. Это 
ограничение заставляет принимать специальные меры для того, чтобы целостность 
данных не нарушалась в результате отказа, происходящего в промежутке между 
двумя связанными между собой обращениями к базе данных.
Два других важных момента в работе приложения - это подключение и отключение. 
Вполне понятно, что перед тем, как выполнить запрос, необходимо подключиться к 
базе данных. Однако довольно часто забывают о второй стороне медали- 
необходимости «убрать за собой». Следует всегда освобождать все захваченные 
ресурсы базы данных, когда они вам больше не нужны. В долго живущих приложениях,
 таких как демон Интернет, неаккуратно написанная система может понемногу 
отнимать ресурсы базы данных, и, в конце концов, заблокирует систему.
«Уборка за собой» включает в себя правильную обработку ошибок. Хорошие языки 
программирования затрудняют пропуск обработчиков исключительных ситуаций (отказ 
сети, повторяющиеся ключи при добавлении, ошибки синтаксиса SQL и т. д.). Но 
независимо от того, какой язык вы избрали, вы обязаны знать, какие 
исключительные ситуации могут возникать при данном вызове API, и в каждой 
исключительной ситуации действовать надлежащим образом. С-библиотеки для MySQL 
и mSQL основываются на представлении базы данных в виде наборов строк. Мы хотим 
этим сказать, что библиотеки С позволяют непосредственно обращаться с данными в 
том виде, в каком они в принципе существуют в базе данных. Глава 13 «С и C++», 
раскрывает практические детали программирования в этой модели с использованием 
С API для MySQL и mSQL.
Доступ к реляционной базе данных из объектно-ориентированной среды выявляет 
особый парадокс: реляционный мир занимается исключительно манипуляциями с 
данными, в то время как мир объектов занимается инкапсуляцией данных внутри 
некоторого набора схем поведения. В объектно-ориентированном приложении база 
данных служит средством сохранения объектов для экземпляров приложения. 
Объектно-ориентированное программирование рассматривает данные запроса не как 
набор строк, а как собрание объектов.
Объектное/реляционное моделирование
Основная проблема, которая встает перед разработчиком объектно-ориентированного 
приложения при использовании реляционной базы данных, это - как отобразить 
реляционные данные в объекты. Первой мыслью может быть попытка отобразить 
атрибуты объекта в поля таблицы. К несчастью, такой подход по ряду причин не 
очень удачен.
* Объекты не хранят только простые данные в своих атрибутах. Там могут