При разработке сложных проектов неизбежно возникает необходимость использования базы данных, но на какой из существующих СУБД * остановить свой выбор? Выбор не так уж и мал: mSQL, PostgreSQL, Oracle, MS SQL и другие, но практически любой приемлемый хостинг, который предоставляет стандартные услуги, включает в них несколько баз данных MySQL. Основанием для этого служит ряд немаловажных причин, и одной из них является то, что MySQL является продуктом класса Open Source (открытые исходные тексты), который можно получить бесплатно (для платформы Windows есть некоторые оговорки). Как правило, сервер и клиент MySQL входят в любой дистрибутив операционных систем семейства BSD (FreeBSD, NetBSD, OpenBSD) и Linux, которые используются на большинстве веб-серверов, но, при необходимости, последнюю версию MySQL для всех поддерживаемых систем (в том числе и для Windows) также можно найти на сайте компании MySQL AB - разработчиков MySQL.
PHP + MySQL = скоростьДругая немаловажная причина популярности MySQL заключается в том, что ее создатели с самого начала разработки этой СУБД поставили во главу угла ее быстродействие, пожертвовав при этом некоторыми удобствами для разработчиков. Связка PHP + MySQL или Perl + MySQL обеспечивают очень высокое быстродействие, которого очень трудно достичь другими средствами. Очень хорошая связь MySQL с PHP стала еще одной причиной популярности этой СУБД. Поддержка MySQL входит в стандартную сборку PHP, и можно быть уверенным, что проблем обращения к серверу MySQL из PHP-скриптов не будет. Для обеспечения взаимодействия PHP с другими СУБД (PostgreSQL, Oracle и так далее) приходится компилировать его самостоятельно из исходных кодов с дополнительными опциями. Таким образом, можно считать, что дешевизна, легкодоступность, производительность и тесная взаимосвязь с PHP и обеспечивают такую популярность MySQL.
Однако считать MySQL идеальной СУБД было бы большой ошибкой. Как известно, наши достоинства - продолжение наших же недостатков, и высокая скорость работы MySQL достигается за счет принесения в жертву удобства разработки, лишая разработчиков многих инструментов и команд, привычных в других СУБД. В MySQL мы не можем пользоваться вложенными подзапросами, процедурами, триггерами, видами и, с некоторыми оговорками, каскадными обновлениями. В версии 4.1 ожидается добавление вложенных подзапросов, а в версии 5 - и другие дополнительные средства, но сможем ли мы ими воспользоваться? На сайте компании MySQL AB доступна версия 4.0, а большинство провайдеров предоставляет нам возможность работы с версией 3.23, поэтому использование нововведений будет в ближайшее время под большим вопросом, если мы хотим, чтобы наши скрипты продолжали работать корректно при смене провайдера.
Тем не менее в руководстве MySQL, которое также можно найти на сайте компании MySQL AB, приведены рекомендации, использование которых поможет свести неудобства от недостатка инструментов к минимуму, а в некоторых случаях - даже извлечь из этого пользу. Например, там, где в других СУБД опираются на концепцию транзакций, которая обеспечивает целостность и согласованность таблиц, фиксируя только законченные изменения, легко откатывая базу данных к последнему согласованному состоянию в случае неудачи, в MySQL применяется концепция "запирания" таблицы перед проведением операций, потенциально опасных для целостности базы данных, не позволяя в этом момент другим соединениям изменять и читать данные с этой таблицы и ставя запросы в очередь. Вложенные подзапросы в большинстве случаев можно переписать в один более сложный запрос, получая еще большее быстродействие, или разбить их на несколько, а ведь в СУБД, где вложенные подзапросы разрешены, программисты иногда даже не задумываются о возможности оптимизации вложенных позапросов. Помимо этого, в MySQL есть и альтернативные способы хранения таблиц в базе данных (InnoDB), которые не используются по умолчанию, но тем не менее поддерживают концепцию транзакций, обеспечивая привычные механизмы отката неудачных операций и предоставляя дополнительные инструменты - например, каскадные удаления и так далее, - правда, в ущерб тому же быстродействию базы данных. В других случаях создатели MySQL прямо говорят, что в некоторых ситуациях лучше использовать другие СУБД, как, например, при необходимости хранения и обработки географической информации, где преимуществами будет обладать PostgeSQL, в которой есть специализированные поля для хранения подобной информации, и функции для их обработки. Поэтому, если ваша информация имеет очень специализированный уклон и не совсем хорошо описывается в терминах чисел, строк, дат, текста, требуя конструирования специфических структур, то, возможно, следует обратить внимание на возможности других СУБД. Но, в любом случае, для большинства веб-проектов возможностей MySQL более чем достаточно.
Как и в большинстве современных СУБД, для создания запросов серверу MySQL применяется язык SQL * (Structured Query Language - язык структуированных запросов). Можно считать, что в настоящее время SQL является стандартом работы с базами данных. Но необходимо помнить, что несмотря на существующие стандарты SQL, в разных СУБД его реализации могут отличаться, то есть существуют так называемые "диалекты" SQL. Язык запросов в MySQL придерживается стандарта ANSI SQL92, но включает в себя специфические ключевые слова, которых нет в этом стандарте. Например, практически во всех таблицах будет присутствовать в столбцах, обеспечивающих уникальность записей, свойство "AUTO_INCREMENT", которое не поймут другие СУБД, если вы попытаетесь там выполнить команды SQL, созданные вами для MySQL. Если вы планируете в дальнейшем перенос ваших программ на другие СУБД, то следует уделить больше внимания этому вопросу совместимости диалектов, тем более что MySQL позволяет использовать многие дополнительные ключевые слова в командах SQL в целях совместимости, игнорируя их во время выполнения. Расширение в будущем возможностей MySQL также связано с переходом к другому диалекту SQL, соответсвующему стандарту ANSI SQL99, в котором реализовано больше возможностей для СУБД.