su13@pochta.ru

| Первый | Второй | Третий | Четвёртый | Пятый | Шестой | Седьмой |


Часть I.

Начинаем изучение MySQL и mSQL

Первая часть этой книги познакомит вас с понятием и архитектурой реляционной базы данных. Мы углубляемся здесь в детали самых первых шагов изучения MySQL и mSQL. Возможно, вы уже имеете опыт общения с одним из этих великолепных программных продуктов и ждете, что книга станет вашим помощником в работе. Если это так, вы можете просто сосредоточиться на выбранном вами продукте и не отвлекаться на остальные. С другой стороны, если вы еще не сделали свой выбор, этот раздел расскажет вам об особенностях MySQL и mSQL, дабы вы не ошиблись в выборе. К концу этой части, после благополучной установки и конфигурирования вашей базы данных, вы будете готовы к подробному изучению программирования баз данных, которому мы посвятили вторую часть нашей книги.

Глава №1.

Введение в реляционные базы данных

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

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

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

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

ном мире. Если у вас есть опыт работы с реляционными базами данных и их проектированием, вы можете сразу перейти к главе 4, «MySQL» или главе 5, «mSQL», где мы углубляемся в детали практической работы с MySQL и mSQL. Но, если вы собираетесь это сделать, обратите внимание, что в конце данной главы мы приводим краткое введение и сравнение основных возможностей этих продуктов. В оставшейся части книги в основном излагается применение MySQL и mSQL для создания и поддержки того типа приложений, которые важны для таких пользователей, как вы.

Что такое база данных?

База данных - это, попросту говоря, собрание данных. Примером неэлектронной базы данных является общественная библиотека. В библиотеке хранятся книги, периодические издания и прочие документы. Когда нужно отыскать в библиотеке какие-либо данные, вы просматриваете каталог либо указатель периодики или даже справляетесь у библиотекаря. Другой пример - неупорядоченная стопка бумаг, которая может находиться у вас на столе. Когда нужно что-то найти, вы роетесь в этой кипе, пока не найдете нужный листок. Эта база данных может работать (или нет), поскольку ее размер крайне мал. Стопка бумаг, несомненно, будет неэффективна для большого объема данных, такого, например, как библиотечное собрание. Библиотека без картотеки, индекса периодики и библиотекаря останется базой данных, только ей нельзя будет пользоваться. Поэтому, чтобы библиотека имела какую-то ценность, она должна быть организована каким-либо способом. Вашей стопкой бумаг можно было бы пользоваться более уверенно при наличии упорядоченной системы их хранения (тогда, возможно, вы не потеряли бы тот телефонный номер!). Поэтому, уточняя наше определение, мы скажем, что база данных - организованное собрание данных.

У библиотеки и стопки бумаг много сходства. Та и другая являются базами данных, состоящими из документов. Нет никакого смысла, однако, соединять их вместе, поскольку ваши документы интересны только вам, а библиотека содержит документы, представляющие общий интерес. Каждая из баз данных отвечает определенному назначению и организована в соответствии с этим назначением. Поэтому мы еще несколько улучшим наше определение: база данных есть собрание данных, которые организованы и хранятся в соответствии с некоторым назначением.

У традиционных бумажных баз данных много недостатков. Им требуется огромное физическое пространство. Библиотеки занимают целые

здания, и поиск в них осуществляется относительно медленно. Каждый работавший в библиотеке знает, что для поиска порой требуется немало времени. Библиотеки также утомительно содержать в порядке, и для поддержания соответствия содержимого полок и каталогов требуется чрезмерно много времени. Хранение базы данных в электронном виде помогает решать эти вопросы.

MySQL и mSQL не являются базами данных. Фактически они являются компьютерными программами, позволяющими пользователю создавать, поддерживать базы данных и управлять ими. Такой тип программного обеспечения известен как Системы управления базами данных (СУБД). СУБД действует как посредник между физической базой данных и ее пользователями.

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

Что такое реляционная база данных?

Согласно нашему определению, база данных является организованным собранием данных. Реляционная база данных организует данные в таблицы. Вероятно, проще проиллюстрировать понятие таблицы, чем пытаться объяснить его. Таблица 1-1 является примером таблицы, которая может появиться в базе данных по книгам.

Таблица 1-1. Таблица книг

ISBN

Название

Автор

0-446-67424-9

0-201-54239-Х

0-87685-086-7

0-941423-38-7

L.A. Confidential

An Introduction to Database Systems

Post Office

The Man with the Golden Arm

James Ellroy

C.J. Date

Charles Bukowski

Nelson Algren

В таблице 1-2 и таблице 1-3 показаны две таблицы, которые могут появиться в базе данных Национальной Баскетбольной Ассоциации.

Таблица 1-2. Таблица команд НБА

№ команды

Название

Тренер

1

Golden State Warriors

P.J. Carlesimo

2

Minnesota Timberwolves

Flip Saunders

3

L.A. Lakers

Kurt Rambis

4

Indiana Pacers

Larry Bird

 

Таблица 1-3. Таблица игроков НБА

Имя

Положение

№ команды

Rik Smits

Центровой

4

Kevin Garnett

Нападающий

2

Kobe Bryant

Защитник

3

Reggie Miller

Защитник

4

Stephen Marbury

Защитник

2

Shaquille O'Neal

Центровой

3

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

СУБД для реляционной базы данных часто называется Реляционной системой управления базами данных (РСУБД). MySQL и mSQL являются примерами РСУБД.

Какое отношение ко всему этому имеет SQL? Нам необходимо иметь некий способ взаимодействия с базой данных. Нужно определять таблицы, а также извлекать, добавлять, обновлять и удалять данные. SQL (Structured Query Language - язык структурированных запросов) является компьютерным языком, используемым для выражения операций с базой данных, организованной в реляционной форме (то есть в виде таблиц). SQL является принятым в отрасли стандартом языка, на котором говорит большинство программистов баз данных и который используется большинством пакетов РСУБД. Как следует из их названий, механизм работы с MySQL и mSQL основан на SQL. Из-за своей простоты, однако, они поддерживают лишь подмножество современного стандарта SQL - SQL2. Мы обсудим, в чем именно состоит отличие поддерживаемого MySQL и mSQL диалекта SQL от стандарта, в последующих главах.

Приложения и базы данных

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

Базы данных существуют для того, чтобы люди могли с ними взаимодействовать. В случае электронных баз данных взаимодействие происходит не непосредственно с базой данных, а косвенно — с помощью программного обеспечения. До появления Всемирной паутины (World Wide Web) базы данных обычно использовались большими корпорациями для поддержки различных деловых функций - бухгалтерии и финансов, контроля поставок и складского учета, планирования производства, учета персонала и т. п. Интернет и более сложные задачи домашних вычислений содействовали перемещению потребностей в использовании баз данных за пределы больших корпораций.

Базы данных и WWW

Область, в которой развитие баз данных имело особо взрывной характер, и где отличились MySQL и mSQL, - это разработка приложений для Интернет. По мере роста спроса на все более сложные и надежные приложения для Интернет растет и спрос на базы данных. База данных сервера может поддерживать многие важные функции в Интернет. Фактически, любое содержание веб-страниц может управляться базой данных.

Рассмотрим в качестве примера торговца по каталогу, который хочет опубликовать свой каталог в WWW и принимать заказы через Интернет. Если опубликовать каталог в виде HTML-файла, то кому-то придется вручную редактировать каталог всякий раз, когда добавляется новый товар или изменяется цена. Если же вместо этого держать данные каталога в реляционной базе данных, то становится возможной публикация изменений в каталоге в реальном масштабе времени путем простого изменения в базе данных сведений о товаре и цене. Становится также возможной интеграция каталога с имеющимися системами электронной обработки заказов. Таким образом, использование базы данных для управления таким веб-сайтом дает очевидные преимущества как продавцу, так и покупателю.

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

извлекает переданные пользователем данные. Эти программы чаще всего делаются в виде CGI-сценариев или серверных приложений на Java, но возможно также встраивание программы прямо в HTML-страницу. Все эти методы мы рассмотрим в нашей книге.

Теперь ваша программа знает, какие данные нужны пользователю или что он хочет внести в базу данных. Программа формирует команду SQL для выборки или изменения данных, а база данных чудесным образом делает все остальное. Результаты, получаемые от базы данных, ваша программа может оформить в виде новой HTML-страницы и отправить обратно пользователю.

MySQL и mSQL

MySQL и mSQL - очень схожие, дешевые, компактные и быстрые базы данных. В этой книге описаны обе эти базы данных, что связано с их крайним сходством. Однако между ними есть и очень важные различия, о которых мы также обязательно расскажем. Обе системы поддерживают программирование на С, Perl, Java (через API Java DataBase Connectivity - JDBC) и Python. Благодаря инструментальным средствам, которые MySQL и mSQL предоставляют для этих языков, можно создавать полноценные клиент-серверные приложения и интегрированные с базами данных веб-сайты, не тратя на это состояния. Это приятное известие для маленьких фирм, публикующих данные в Интернет, и всех тех, кто разрабатывает небольшие клиент-серверные приложения и не может позволить себе приобрести коммерческие продукты.

Дешевизна, а в некоторых случаях бесплатность, MySQL и mSQL не дается даром. Ни одна из этих СУБД полностью не поддерживает SQL. В них отсутствуют некоторые возможности, которые могут понадобиться при создании более сложных приложений. В некоторых случаях приходится также несколько больше потрудиться, разрабатывая клиентскую часть, чтобы достичь того, что дорогие базы данных предоставили бы вам даром. Однако мы научим вас, как делать переносимые приложения MySQL и mSQL, чтобы вы попробовали использовать какие-либо базы данных с более мощными внутренними механизмами, если это вам понадобится, и вам не пришлось бы переписывать весь код, чтобы перейти на большую базу данных. Для понимания того, что же могут предложить эти две СУБД, лучше всего кратко рассмотреть их историю.

История mSQL

До 1994 года вам не удалось бы обзавестись РСУБД с поддержкой SQL, не потратив при этом изрядной суммы денег. На рынке тогда доминировали Oracle, Sybase и Informix. Эти системы управления базами данных были разработаны для обработки огромных объемов данных с очень сложными взаимосвязями. Они были мощными, обладали множеством возможностей, а также требовали больших вычислительных ресурсов и были дороги. В те времена еще нельзя было за $2000 купить сервер с 200-MHz Pentium. Ресурсы, требуемые для этих СУБД, стоили десятки тысяч долларов.

У больших корпораций и крупных университетов не возникало проблем с тем, чтобы потратить за год несколько миллионов долларов на такие комплекты серверов и СУБД. Малым организациям и частным пользователям приходилось довольствоваться слабыми настольными приложениями. Несколько дешевых СУБД с архитектурой клиент/ сервер в то время существовало, но ни в одной из них не использовался SQL в качестве языка запросов. Наиболее примечательной из них была Postgres, имевшая общее происхождение с коммерческой базой данных Ingres. К несчастью, Postgres требовала примерно тех же ресурсов, что и ее коммерческие аналоги, не давая преимущества использования SQL в качестве языка запросов. В то время в Postgres использовалась разновидность языка QUEL, называвшаяся PostQUEL.

Дэвид Хьюз

Часть диссертации, которую Давид Хьюз (David Hughes) (известный также как Bamby) писал в Университете Бонд в Австралии, была посвящена разработке системы мониторинга и управления группой систем из одного или нескольких мест. Проект носил название Minerva Network Management System. Главным элементом Minerva была база данных для хранения данных обо всех компьютерах в сети. Будучи студентом университета и не имея доступа к серверам, на которых работали большие коммерческие базы данных, Хьюз решил, что Postgres - это очевидное решение, вполне отвечающее его потребностям.

Его коллеги предложили сделать SQL стандартным языком запросов для Minerva. В конце концов, SQL был и остается самым общепринятым стандартом языка запросов. Основываясь на SQL, Minerva могла бы использоваться в любой точке света, где установлена поддерживающая SQL СУБД. Иными словами, SQL предоставлял возможности Minerva гораздо более широкому кругу пользователей, нежели PostQUEL, ограничивавший его пользователями Postgres. В конечном итоге оказалось, что сегодня даже Postgres поддерживает SQL.

Желание пользоваться стандартом SQL, с одной стороны, и отсутствие доступа к базе данных, поддерживающей SQL, - с другой, поставили Хьюза в трудное положение. Если использовать в Minerva язык запросов, основанный на SQL, то не удастся найти СУБД с соответствующим механизмом работы. Не имея возможности приобрести дорогую РСУБД, Хьюз нашел творческое решение проблемы: выход в том, чтобы создать программу, «на лету» транслирующую запросы SQL в запросы PostQUEL. Такая программа должна была перехватывать все

посылаемые Minerva предложения SQL, преобразовывать их в PostQUEL и результат пересылать дальше в Postgres. Хьюз написал такую программу и назвал ее miniSQL, или mSQL.

От транслятора PostQUEL к РСУБД

В течение некоторого времени такая конфигурация удовлетворяла потребности Хьюза. Для Minerva было безразлично, какая СУБД используется, если только она понимает SQL, и она считала, что Postgres понимает SQL, поскольку в середине находился mSQL, производивший трансляцию в PostQUEL. К несчастью, по мере роста Minerva ее работа стала значительно замедляться. Стало ясно, что ни Postgres, ни другая большая РСУБД не смогут поддерживать тот небольшой набор возможностей, который требовался для Minerva, на тех ограниченных ресурсах, которые были ей доступны. Например, для Minerva требовалось одновременное подключение к нескольким базам данных. Для поддержки этого Postgres требовал одновременного запуска нескольких экземпляров* сервера базы данных. Кроме того, несколько потенциальных участников проекта не могли принять в нем участие, поскольку Postgres не поддерживал их системы, а они не могли позволить себе купить дорогую СУБД с поддержкой SQL.

Оказавшись перед лицом этих проблем, Хьюз пересмотрел свое отношение к Postgres. По своим размерам и сложности она, возможно, превышала потребности Minerva. Большинство запросов, генерируемых Minerva, представляли собой простые операторы INSERT, DELETE и SELECT. Все остальные возможности, имевшиеся в Postgres и снижавшие производительность, просто не требовались для Minerva.

У Хьюза уже был mSQL, осуществлявший трансляцию SQL. Ему требовалось только добавить хранилище данных и возможности извлечения данных, чтобы получить сервер базы данных, удовлетворявший его потребности. Эта эволюция привела к существующему на сегодняшний день mSQL.

История MySQL

Было бы ошибкой рассматривать MySQL просто как ответ на недостатки mSQL. Ее изобретатель Майкл Видениус (известный также как Monty) из шведской компании ТсХ работает с базами данных с 1979 г. До недавнего времени Видениус был в ТсХ только разработчиком. В 1979 г. он разработал для внутрифирменного использования средство управления базами данных под названием UNIREG. После 1979 года UNIREG была переписана на нескольких разных языках и расширена для поддержки больших баз данных.

Каждый из процессов, в котором выполняется одна и та же-программа, называется экземпляром этой программы, поскольку он занимает память точно так же, как экземпляр переменной занимает память программы.

В 1994 г. ТсХ стала разрабатывать приложения для WWW, используя для поддержки этого проекта UNIREG. К несчастью, UNIREG из-за больших накладных расходов не могла успешно использоваться для динамической генерации веб-страниц. И ТсХ начала присматриваться к SQL и mSQL. В то время, однако, mSQL существовала только в виде релизов 1.x. Как мы уже говорили, версии mSQL 1.x не поддерживали никаких индексов и поэтому по производительности уступали UNIREG.

Видениус связался с Хьюзом, автором mSQL, чтобы узнать, не заинтересуется ли тот подключением mSQL к обработчику В+ ISAM в UNIREG. Хьюз, однако, к тому времени уже далеко продвинулся на пути к mSQL 2 и создал средства для работы с индексами. ТсХ решила создать сервер баз данных, более соответствующий ее нуждам.

В ТсХ работали неглупые люди, которые не стали изобретать велосипед. Они взяли за основу UNIREG и использовали утилиты сторонних разработчиков для mSQL, число которых все увеличивалось, написав для своей системы API, который, по крайней мере первоначально, почти совпадал с API для mSQL. В результате любой пользователь mSQL, желавший перейти на более богатый возможностями сервер баз данных ТсХ, должен был внести в свой код очень незначительные изменения. Тем не менее исходный код новой базы данных был полностью оригинальным.

К маю 1995 г. у ТсХ имелась база данных, удовлетворявшая внутренние потребности компании, - MySQL 1.0. Бизнес-партнер фирмы Давид Аксмарк (David Axmark) из Detron HB стал убеждать ТсХ представить свой сервер в Интернет. Цель представления сервера в Интернет -использование бизнес-модели, пионером которой был Аладдин Петер Дейч (Aladdin Peter Deutsch). Результатом стали очень гибкие авторские права, которые делают MySQL «более бесплатной», чем mSQL.

Что касается названия, то Видениус говорит об этом так: «До конца не ясно, откуда идет название MySQL. В ТсХ базовый каталог, а также значительное число библиотек и утилит в течение десятка лет имели префикс «mу». Вместе с тем мою дочь (на несколько лет младше) тоже зовут Май (My). Поэтому остается тайной, какой из двух источников дал название MySQL».

С момента публикации MySQL в Интернет она перенесена на многие UNIX-системы, под Win32 и OS/2. ТсХ считает, что MySQL использует около 500 000 серверов.

Основные изменения, внесенные в текущую рекомендованную версию 3.22:

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

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

MySQL или mSQL?

Конечно, мы еще не дали вам сведений, достаточных для принятия решения. Чтобы полностью оценить существующие на сегодняшний день различия между двумя продуктами, необходимо прочесть эту книгу и понять тонкости, представленные нами здесь. На первый взгляд кажется несомненным, что предпочтение следует отдать MySQL. mSQL с течением времени отстала и сейчас уступает в скорости работы. Дэвид Хьюз неудовлетворен и работает над версией 2.1, в которой должны быть устранены многие нынешние недостатки. А в это же время MySQL движется вперед со скоростью света.

Выбор mSQL может быть продиктован имеющимся у вас инструментарием. Поскольку mSQL существует дольше, вам может оказаться легче найти инструмент, отвечающий вашим специфическим потребностям. К примеру, в момент написания этой книги только для mSQL имелся драйвер JDBC, соответствующий JDBC 2.0. Конечно, положение изменится к тому времени, когда вы прочтете книгу. Тем не менее при выборе базы данных следует руководствоваться соображениями такого типа.

Независимо от того, какую базу данных вы выберете, вы окажетесь в выигрыше. Обе эти базы данных обеспечат большее быстродействие, чем при любом другом выборе. Для объективного сравнения этих баз данных друг с другом и другими продуктами рекомендуем посетить страницу http://www.mysql.com/crash-me-choose.htmy. Она находится на домашней странице MySQL, но представленные на ней критерии можно свободно проверить, а сама страница сделана очень хорошо.

Оглавление

GNU OCXE GNU LINUX
Сайт управляется системой uCoz