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, но представленные на ней критерии можно свободно проверить, а сама страница сделана очень хорошо.
