Добрый день!

Хочется задать вот какой вопрос. Насколько велики различия между SQL -диалектами у разных СУБД? Например, у MySQL, PostgreSQL, MSSQL, Oracle...? То есть, конечно, понятно, что SQL - это стандарт. Но одинаково ли все СУБД его поддерживают?

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

Буду рад узнать опыт людей, занимавшимся таким, имеющих опыт. Спасибо!

"Различия не столько в диалекте (хотя они есть, и их не так мало)"

Гм, а если строго придерживаться SQL -стандарта, могу я расчитывать на адекватную их работу во всех СУБД?

Да, конечно, придется исключить неподдерживаемые всеми СУБД функциями, вроде триггеров и хранимых процедур.

Собственно, всё, что хочется - это SELECT, UPDATE, REPLACE, INSERT. Довольно простые условия.

Хотя, на этом думается, стоит ли вообще распылять себя на разные БД (тем более, такие, какие вряд ли будут на хостинге - вроде Oracle) и сконцентрироваться на максимальной поддержке и качества кода для одной-двух СУБД?

• В MySQL 4.0 нет поддержки вложенных запросов(отказ от вложенных запросов или ограничение версий)
• В Pg (в Orcale вроде тоже) нет возможности сортировать по полям не входящим в DISTINCT выборку(вложенные запросы)
• В Pg отвратительная оптимизация DISTINCT запросов(обходится усложнением логики построения запроса)
• СУБД по разному сортируют NULLы (ничего не поделать, возможно можно настроить на сервере)
• В Oracle нет LIMIT, OFFSET(эмуляция через вложенные запросы)
• По разному интерпретируются начальные и конечные пробелы в CHAR полях (приходится приводить к одному виду)
• В MySQL при обычных настройках обрезается строка при превышении длинны без сообщении о ошибке
• В MySQL поиск обычно case insensetive, а в Pg нужно для этого использовать LOWER или ILIKE, оба варианта могут замедлить производительность (не помню какой быстрее).
• В Pg нет возможности использовать альяс в конструкции FROM до его определния.
• Разный подход к обработке строк: кодировки, валидность, длинна, экранирование...

Это маленький список того, что вспомнилось сходу.

Василий Свиридов[досье]

Вам проще будет пользоваться готовой библиотекой абстракции, типа Pear:: DB .

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

З.Ы. Для меня совсем недавно стало откровением что в MSSQL"е нет даже примерного аналога offset"а или rownum(). (для мускуля: limit a,b). В результате adodb"шный лимит пришлось юзать да и тот тормозил (что естественно)

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

p.s.
я всегда, по возможности, стараюсь жёстко зацепиться за платформу, и пользовать её по максимуму. (Правда и софт в основном пишу по заказу, под конкретную платформу)

Вообще, правильное решение тут — вынесение всего общения с базой на отдельный уровень модели. Тогда при возможном портировании с SQLLite на Oracle потребуется переписать только этот уровень. Пытаться же писать совместимые SQL -запросы, мне кажется, бесполезно — слишком большой бардак в диалектах.

Давид Мзареулян[досье] Странно звучит фраза, ведь если можно переписать уровень модели под другую базу не трогая остальные уровни, то значит у вас уже есть абстракция от особенностей БД и ничего не мешает сделать динамический выбор между реализациями.

Василий Свиридов[досье] Чем большое количество присоединений и подзапросов отличается от малого? Мне кажется ничем. И система, которая умеет строить одно присоединение, может строить и 10-ть.

2all: Вопрос в дизайне таких систем, достаточно сложно разработать гибкий дизайн, который позволит в полной мере использовать расширения той или иной СУБД, потому что иногда просто невозможно сделать приемлимую эмуляцию поведения на других БД. В таких случаях приходится жертвовать производительность и/или гибкостью.

Давид Мзареулян[досье] Где-то так, так как задача прикладного характера и не является отдельным законченным продуктом, а только инструментом, то разрабатываться и развиваться должна только в рамках конкретных проектов.

Закиров Руслан[досье] Отличается тем, что человек, имхо, сможет намного более эффективно соптимизировать сложный запрос, нежели скрипт. Хотя-бы потому, что человек может при этом учитывать схему базы и он знает, где можно жертвовать производительностью, а где - ну никак нельзя. (Моя аргументация правда начинает уходить от абстракции, так что на этом я закончу. А то оффтоп злостный пойдёт;))

Язык

Представьте себе город (назовем его А), в котором все говорят на одном языке. На нем строятся все бизнес-процессы, этот язык используется во всех формах общения. Словом, жители этого города понимают друг друга и исследуют окружающий мир только посредством этого языка. Если сменить язык в одном месте, все будут сбиты с толку.

А теперь представьте другой город Б, в котором все дома говорят на разных языках. Все по-разному взаимодействуют с миром, нет никакого «универсального» способа понимания или устойчивой организации общения. Если один что-то изменит, это ни на кого не повлияет.

Этот пример помогает проиллюстрировать одно из основных различий между SQL (реляционной) и NoSQL (нереляционной) базами данных. Из него уже можно сделать определённые выводы.

Реляционные базы данных используют язык структурированных запросов (SQL) для того, чтобы обрабатывать данные и управлять ими. С одной стороны, это довольно удобно: SQL - один из наиболее разносторонних и общеупотребимых вариантов, так что это безопасный выбор. Также этот язык подходит для сложных запросов. С другой стороны, с этим языком идут определенные ограничения. В SQL нужно использовать заданные наперед схемы и определять структуру данных перед началом работы с нею. К тому же, все данные должны иметь одну и ту же структуру. Как в случае с городом А, перемена в структуре может обернуться сложностями и разрушить всю систему.

Нереляционные базы данных , напротив, обладают гибкими схемами для неструктурированных данных. Они могут храниться по-разному: в колонках, документах, графах или в виде хранилища «ключ-значение». Эта гибкость позволяет:

• Можно создавать документы, не определяя их структуру заранее;
• Каждый документ может обладать собственной уникальной структурой;
• Синтаксис может различаться в разных базах данных;
• В процессе работы можно добавлять новые поля.

Масштабируемость

В большинстве случаев SQL БД можно масштабировать вертикально, то есть можно проводить увеличение нагрузки на каждом отдельном сервере, повышая мощности ЦП, ОЗУ, твердотельного диска. А вот NoSQL БД можно масштабировать горизонтально. Это значит, что нагрузка распределяется благодаря разделению данных или добавлению большего количества серверов. Это как если бы вы добавляли больше этажей к зданию либо добавляли больше зданий к району. В последнем варианте система может получиться более крупной и мощной. Именно поэтому для крупных или часто меняющихся БД обычно выбирают NoSQL.

Структура

SQL БД имеют форму таблиц, а в NoSQL БД данные представляются в виде документов, пар «ключ-значение», графов или хранилищ wide-column. Из-за этого реляционные (SQL) базы лучше использовать для приложений, в которых нужно переходить между несколькими записями (например, система бухучета), или для систем устаревшего вида, которые при создании имели реляционную структуру.

Примерами SQL БД являются ySQL, Oracle, PostgreSQL и Microsoft SQL Server, а NoSQL БД - MongoDB, BigTable, Redis, RavenDB Cassandra, HBase, Neo4j и CouchDB.

SQL против NoSQL: MySQL либо MongoDB

Раз уж мы разобрались, в чем состоит разница SQL и NoSQL, рассмотрим ключевые различия между ними на примере MySQL и MongoDB.

MySQL: SQL (реляционная) база данных

Ниже представлены сильные стороны MySQL:

• Сформированность: MySQL - хорошо известная база данных, то есть она обладает крупным коммьюнити, широкими возможностями тестирования и стабильностью;
• Совместимость: MySQL доступна на всех основных платформах, включая Linux, Windows, Mac, BSD и Solaris. Также у нее есть адаптеры для таких языков, как Node.js, Ruby, C#, C++, Java, Perl, Python и PHP, то есть эта система не ограничена языком запросов SQL;
• Экономичность: Система является открытой и бесплатной;
• Воспроизводимость: Базу данных MySQL можно использовать на разных узлах, что позволяет снизить нагрузку и повысить масштабируемость и доступность приложения;
• Разделение данных: Несмотря на то что эту процедуру можно проводить на не всех SQL БД, серверы MySQL позволяют это сделать. Это не только экономично, но и может быть полезно для приложения.

MongoDB: NoSQL (нереляционная) база данных

Ниже представлены сильные стороны MongoDB:

• Динамичность: Как говорилось ранее, динамическая схема гарантирует гибкость, позволяющую менять структуру без редактирования существующих данных;
• Масштабируемость: MongoDB можно масштабировать горизонтально, благодаря чему уменьшается нагрузка для бизнеса;
• Легкость в управлении: Для этой базы данных не требуется администратор. Так как она достаточно дружелюбна в отношении юзеров, воспользоваться ей могут как разработчики, так и администраторы;
• Скорость: Эта БД показывает отличные результаты в работе с короткими запросами;
• Гибкость: В MongoDB можно добавлять новые столбцы и поля, не влияя на уже существующие записи и производительность приложения.

Какую базу данных выбрать для своего проекта?

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

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

Отличия MySQL от стандартного SQL

В состав сервера MySQL входит ряд расширений, которых, возможно, вы не найдете в других базах данных SQL. Помните, что если вы используете их, ваш код перестанет быть переносимым на другие серверы SQL. В некоторых случаях вы можете писать код, включающий расширения MySQL, но остающийся переносимым, используя для этого форму комментариев /*! ... */. В этом случае сервер MySQL разбирает и выполняет код внутри комментария, как и любые другие SQL-операторы, а все другие серверы SQL расширение проигнорируют. Например: SELECT /*! STRAIGHT_JOIN */ имя_столбца FROM таблица1, таблица2 WHERE ... Если после символа "!" добавить номер версии, синтаксис внутри комментария будет выполняться только сервером MySQL указанной и более поздних версий: CREATE /*132302 TEMPORARY */ TABLE t (a INT); Это означает, что если работа выполняется в версии MySQL 3.23.02 или более позд­ней, то ключевое слово TEMPORARY будет использовано. В приведенном ниже списке описаны расширения MySQL по категориям.

• Организация данных на диске.

Сервер MySQL отображает каждую базу данных на подкаталог внутри каталога данных MySQL, а таблицы внутри базы - на имена файлов в этом каталоге. От­сюда вытекает несколько следствий:

1. Имена баз данных и таблиц MySQL зависят от регистра в средах операцион­ ных систем, в которых имена файлов чувствительны к регистру символов (большинство Unix-систем).
2. Можно использовать стандартные системные команды для резервного копиро­ вания, переименования, перемещения, удаления и копирования таблиц, управляемых механизмами хранения My ISAM или ISAM.

Например, чтобы переименовать таблицу MylSAM, потребуется переименовать файлы.MYD, .MYI и. frra, ко­торые относятся к таблице. Имена баз данных, таблиц, индексов, столбцов и псевдонимы могут начинаться с цифры (но не должны состоять только из цифр).

• Общий синтаксис языка.

1. Строки могут ограничиваться и одиночными и двойными кавычками.
2. Символ "V используется в строках как управляющий.
3. Внутри SQL-операторов можно получать доступ к таблицам из разных баз дан­ ных посредством синтаксиса имя_ базы_ да нных. имя таблицы. Некоторые серверы SQL предоставляют ту же функциональность, но называют ее пространством пользователя (User space). Сервер MySQL не поддерживает табличных про­ странств, как в следующем операторе: CREATE TABLE ralph.my_table.. .IN my_tablespace.

• Синтаксис SQL-операторов.

1. Операторы ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE И REPAIR TABLE.
2. Операторы CREATE DATABASE И DROP DATABASE.
3. Оператор DO.
4. EXPLAIN SELECT - для получения описания способа объединения таблиц в за­ просе.
5. Операторы FLUSH и RESET.
6. Оператор SET.
7. Оператор show.
8. LOAD DATA INFILE. Во многих случаях этот синтаксис совместим с аналогич­ ным синтаксисом Oracle.
9. RENAME TABLE.
10. REPLACE вместо DELETE + INSERT.
11. Конструкции CHANGE имя_столбца, DROP имя_столбца, DROP INDEX, IGNORE и RENAME в операторе ALTER TABLE. Использование множественных конструкций ADD, ALTER, DROP И CHANGE в операторе ALTER TABLE.
12. Использование имен индексов, индексов в префиксах полей, а также конст­ рукций INDEX ИЛИ KEY В операторе CREATE TABLE.
13. Использование IF EXISTS вместе с DROP TABLE.
14. Можно удалять несколько таблиц одним оператором DROP TABLE.
15. Конструкции ORDER BY и LIMIT В операторах UPDATE И DELETE.
16. Синтаксис INSERT INTO...SET имя_столбца = ....
17. Конструкция DELAYED в операторах INSERT и REPLACE.
18. Конструкция LOW_PRIORITY В операторах INSERT, REPLACE, DELETE И UPDATE.
19. Использование INTO OUTFILE и STRAIGHT_JOIN в операторе SELECT.
20. ОПЦИЯ SQL_SMALL_RESULT оператора SELECT.

Нет необходимости перечислять все выбранные столбцы в конструкции GROUP BY. Это обеспечивает лучшую производительность для некоторых очень спе­ цифических, но вполне нормальных запросов.

Можно применять ASC или DESC вместе с GROUP BY.

Имеется возможность присваивать значения переменным с помощью операции присваивания:= в операторах:

mysql; SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg -; FROM test_table; mysql; SELECT @tl:=(@t2:=l)+@t3:=4,@tl,@t2,@t3; м Типы столбцов. Типы столбцов mediumint, set, enum и различные варианты типов blob и text. Атрибуты столбцов AUTO_INCREMENT, BINARY, NULL, UNSIGNED И ZEROFILL.

• Функции и операции.

1. Чтобы облегчить жизнь пользователям, привыкшим к другим SQL-средам, сервер MySQL поддерживает псевдонимы для многих функций. Например, все строковые функции поддерживают как стандартный синтаксис SQL, так и син­ таксис ODBC.
2. Сервер MySQL воспринимает операции и | | как логическое И (AND) и логическое ИЛИ (OR), по аналогии с языком программирования С. В кон­ тексте сервера MySQL операции | | и OR являются синонимами, равно как и и AND. По этой причине MySQL не поддерживает стандартную SQL-операцию | | для конкатенации строк. Вместо этого необходимо применять функцию CONCAT (). Поскольку CONCAT () принимает любое количество аргументов, пре­ образовать все операции | | очень легко.
3. Использование COUNT(DISTINCT список), где список содержит более одного элемента.
4. Все сравнения строк по умолчанию чувствительны к регистру, а порядок сор­ тировки определяется текущим выбранным набором символов (по умолчанию ISO-8859-1 Latinl). Если это не подходит, потребуется объявить столбец с ат­ рибутом BINARY либо воспользоваться приведением к BINARY, что заставит вы­ полнять сравнение и сортировку в соответствии с кодами символов, а не в лек­ сикографическом порядке.
5. Операция % является синонимом функции MOD (). То есть, выражение N % м эквивалентно MOD (N, м). "%" поддерживается для удобства программистов на языке С и достижения совместимости с СУБД PostgresSQL.
6. Операции =, о,=, ;=, ;, «, »,=;, AND, OR и LIKE могут применяться для сравнения столбцов слева от конструкции from в операторах SELECT, например: mysql; SELECT col1=1 AND col2=2 FROM имя таблицы;
7. Функция LAST_INSERT_ID () возвращает самое последнее значение AUTO_INCREMENT.
8. LIKE можно применять к числовым столбцам.
9. Расширенные операции обработки регулярных выражений REGEXP и NOT REGEXP.

1. Функции C0NCAT () и CHAR () принимают один и более аргументов.
2. Функции BIT_COUNT(), CASE, ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD!), ENCRYPT (),MD5(), ENCODE(), DECODE (), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS () И WEEKDAY !).
3. Применение TRIMO для усечения подстрок. Стандартный язык SQL поддер­ живает только удаление последовательностей одинаковых символов.
4. Возможность в конструкции GROUP BY обращаться к функциям STD (), BIT__OR(),BIT_AND(),BIT_XOR() И GROUP_CONCAT().

Для ознакомления с перечнем новых расширений, которые планируется добавить в сервер MySQL, а также с их приоритетностью, просмотрите список TODO по адресу http://dev.mysql.com/doc/mysql/en/TODO.html. В настоящем руководстве представле­на последняя на данный момент версия списка TODO. См. также раздел MySQL и будущее (списки TODO).

Прежде, чем приступить к статье, объяснющей разницу между SQL и MySQL , я поздравлю Вас с Новым годом , годом кролика. Желаю в Новом году Вам побольше удачи, побольше целеустремлённости и побольше упорства. Ведь главное в жизни - это достигать своих целей , а они достигаются только упорными людьми. Будьте упорны и настойчивы, и тогда в Новом году Вы будете победителем в любой сфере ! А теперь вернёмся к делу.

Я достаточно часто встречаю вопрос: "Какая разница между SQL и MySQL ", и я решил ответить на этот вопрос, несмотря на всю его абсурдность. Ведь с тем же успехом можно спросить: "Какая разница между сервером Apache и PHP ", но это почему-то никто не спрашивает.

В общем, отвечаю на вопрос. SQL - это язык запросов для управления СУБД (система управления базами данных ). А MySQL - это одна из таких СУБД . В частности, помимо MySQL существуют и другие СУБД : Oracle , MS SQL Server , PostgreSQL и много других. И чтобы работать (сделать выборку, вставить новую запись, добавить новую таблицу и так далее) с любой из этих СУБД необходим язык запросов, и таким языком и является SQL .

• SQL - язык запросов для управления СУБД .
• MySQL - это одна из множества других СУБД .

Надеюсь, я ответил на этот один из самых популярных вопросов среди новичков, которые только начинают заниматься базами данных. Хотя нет, Вы не новички, Вы молодцы ! Как показывает практика, люди не двигаются дальше HTML и CSS (редко JavaScript). И если Вы решили заниматься базами данных, то Вы уже герой! Так что Вы не новички, а просто начинающие познавать действительно важные и, в общем-то, сложные вещи. Удачи Вам в этом!

База данных играет важную роль для каждого современного веб-приложения. Благодаря динамической природе веб-приложений сейчас, даже простейшие приложения требуют некоторых механизмов хранения, доступа и изменения данных (вот почему в Hostinger мы предлагаем для наших клиентов с премиум и бизнес аккаунтами). Естественно, поскольку важность баз данных стремительно растёт, реляционные системы управления базами данных или реляционные СУБД набирают свою популярность (Relational Database Management Systems – RDBMS)

Что такое SQL сервер?

SQL сервер также известен, как Microsoft SQL Сервер, появился значительно раньше, чем MySQL. Microsoft разработал SQL сервер в 80х, с обещанием разработать надёжную и расширяемую реляционную СУБД. Они остаются ядром качества SQL сервера по прошествии всех этих лет, и предоставляют незаменимое решение для крупномасштабного корпоративного программного обеспечения.

SQL сервер больше подходит для разработчиков, использующих.NET в качестве языка разработки, как конкурирующей связке PHP для MySQL. Это весьма логично, так как обе платформы принадлежать Microsoft.

Ключевые различия между MySQL и SQL сервером

Теперь, после краткого знакомства с системами, давайте посмотрим на несколько ключевых различий между MySQL и SQL сервером:

• Среда
  Как упоминалось ранее, SQL сервер лучше работает с.NET, в то время как MySQL может был использован с практически любыми другими языками, наиболее распространённая связка с PHP. Не лишним будет также сказать, что SQL сервер может быть запущен только лиш под ОС Windows, но за последние годы это условие изменилось, когда Microsoft анонсировала поддержку Linux для SQL сервера . Версия для Linux всё ещё зреет и имеет незавершённых вид, что значит мы рекомендуем вам использовать ОС Windows при работе с SQL сервером и переключатся на Linux, если работаете с СУБД MySQL.
• Синтаксис
  Для большинства людей это наиболее важное различие в этих двух системах. Знакомство с одним набором правил синтаксиса может значительно повлиять на ваше решение относительно того, какая система подходит вам больше. Хотя MySQL и SQL сервер базируются на SQL, различия синтаксиса всё же ощутимы и заслуживают внимания. Например, давайте посмотрим на этот фрагмент:

SELECT age FROM person ORDER BY age ASC LIMIT 1 OFFSET 2

Microsoft SQL Server

SELECT TOP 3 WITH TIES * FROM person ORDER BY age ASC

Обе цепочки кода достигают одного и того же результата – возвращают 3 записи со значением самого молодого возраста из таблицы имён людей. Но синтаксис сильно отличается. Конечно, синтаксис – это субъективный параметр оценки, поэтому мы не может тут давать рекомендацию; выбирайте то, что кажется вам более интуитивно понятным. Полный список описательных различий между MySQL и SQL сервером можно найти (англ.).

• SQL сервер больше, чем реляционная СУБД
  Главное преимущество платного ПО в сравнении с бесплатным – это особая поддержка, которую вы получаете. В данном случае, преимущество ещё более значимое, так как SQL сервер поддерживается одной из самых больших компаний в мире. Microsoft создало дополнительный инструменты для SQL сервера, которые привязываются к реляционной СУБД, включая инструменты для анализа данных. Система также имеет сервер отчётов – Служба отчётов SQL Сервера, равно как и инструмент ETL. Это делает SQL сервер швейцарским армейский ножом среди реляционных СУБД. Вы можете получить подобные функции и в MySQL, но вам придётся искать в интернете сторонние решения – что многим не подойдёт.
• Система хранения данных
  Другим большим различием между MySQL и SQL сервером, которое иногда упускают, это система хранения данных. SQL сервер использует единую систему, разработанную Microsoft, в сравнении с множеством движков, предлагаемых MySQL. Это даёт разработчикам, использующим MySQL больше гибкости, поскольку они могут выбирать разные системы для разных таблиц, основываясь на скорости, надёжности или каких-то других параметрах. Популярный движок MySQL – это InnoDB, который немного теряет в скорости, но обеспечивает усиленную надёжность. Другой известный – MyISAM.
• Отмена запроса
  Немногие это знают, но кардинальным различием между MySQL и SQL сервером является то, что MySQL не позволяет вам отменить запрос в середине его выполнения. Это значит, что, как только команда запущена на выполнение, вам лучше надеяться, что любой ущерб, который она может сделать, является обратимым. SQL сервер, с другой стороны, позволяет вам отменить запрос на пол пути его выполнения. Это различие может быть несущественным для администраторов, так как они обычно выполняют скрипты команд, и это редко требует отмены во время их выполнения, чего не всегда скажешь о разработчиках.
• Безопасность
  Очевидно не требуется тщательного рассмотрения вопроса, когда идёт речь о сравнении различий в безопасности в MySQL с SQL сервера. Обе системы совместимы с EC2, что означает вы в безопасности, выбирая любую из двух. Нужно отметить, что величие Microsoft сказалось и здесь наличием в SQL сервере собственной, ультрасовременной системы безопасности. Выделенный инструмент безопасности – анализатор Microsoft Baseline Security Analyzer (MBSA) – гарантирует надёжную защиту для SQL сервера. Поэтому, если безопасность имеет ключевое значение для вас, выбор очевиден.
• Стоимость
  Здесь SQL сервер становится гораздо менее привлекательным, и MySQL зарабатывает большие очки. Microsoft требует, чтобы вы покупали лицензии для запуска нескольких баз данных на SQL сервер, есть бесплатная версия, но она предназначена только для ознакомления с реляционной СУБД. Напротив, MySQL использует лицензию GNU, что делает её полностью свободной. Однако, если вам нужна поддержка или помощь для MySQL, вам нужно будет заплатить за нее.
• Поддержка сообщества
  Что переносит нас к следующей точке. За поддержка MySQL вам вряд ли придётся платить, за исключением, быть может, редких случаев, благодаря вкладу большого сообщества в его поддержку. Преимущество огромного сообщества в том, что большинству людей не нужно обращаться за специальной помощью – можно просто искать в Интернете и находить массу решений.
• IDE
  Важно отметить, что обе реляционные СУБД поддерживаются различными интегрированными средами разработки (IDE). Эти инструменты предлагают слаженную среду для разработки, и вы можете тщательно выбрать именно то, что лучше всего подходит для ваших потребностей. MySQL может похвастаться Oracle Enterprise Manager, в то время как SQL сервер использует Management Studio (SSMS). Оба имеют свои плюсы и минусы и могут сбить с толку, если у вас нет чётких критериев для обоснования своего решения.

Заключение

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

В этом руководстве мы обсудили две наиболее распространенные реляционные СУБД – MySQL и Microsoft SQL сервер. Мы рассмотрели несколько ключевых различий между MySQL и SQL сервером, даже одного из которых может быть достаточно, чтобы сделать выбор.

В конечном счёте, выбор за вами. Как правило, если вы разрабатываете приложения среднего и малого размера и преимущественно используете PHP, переходите к MySQL. Принимая во внимание, что если вы заинтересованы в создании крупномасштабных, безопасных, устойчивых корпоративных приложений, SQL сервер может вам подойти куда больше.