Добрый день!
Хочется задать вот какой вопрос. Насколько велики различия между SQL -диалектами у разных СУБД? Например, у MySQL, PostgreSQL, MSSQL, Oracle...? То есть, конечно, понятно, что SQL - это стандарт. Но одинаково ли все СУБД его поддерживают?
Сам я работал только с MySQL. И создавая серьёзный проект (PHP) с прицелом на будущее, хочется на архитектурном уровне предусмотреть возможность работы с другими СУБД. И сейчас решаю, как это лучше сделать. Достаточно ли будет создать функцию-обертку для вызова SQL-запроса или придётся создавать функцию для каждого действия с БД, которая в зависимости от выбранной СУБД будет посылать запросы для СУБД на понятном ей SQL-диалекте?
Буду рад узнать опыт людей, занимавшимся таким, имеющих опыт. Спасибо!
"Различия не столько в диалекте (хотя они есть, и их не так мало)"
Гм, а если строго придерживаться SQL -стандарта, могу я расчитывать на адекватную их работу во всех СУБД?
Да, конечно, придется исключить неподдерживаемые всеми СУБД функциями, вроде триггеров и хранимых процедур.
Собственно, всё, что хочется - это SELECT, UPDATE, REPLACE, INSERT. Довольно простые условия.
Хотя, на этом думается, стоит ли вообще распылять себя на разные БД (тем более, такие, какие вряд ли будут на хостинге - вроде Oracle) и сконцентрироваться на максимальной поддержке и качества кода для одной-двух СУБД?
Василий Свиридов[досье]
Вам проще будет пользоваться готовой библиотекой абстракции, типа Pear:: DB .
Я эту фразу с недавних пор считаю в крайней степени не правдой.
Ибо уровнем абстракции придется учиться пользоваться отдельно. Зачастую различия в синтаксисе встречаются там, где их совсем не ждешь. И, хоть и в большинстве ADBL есть инструменты "универсализации", не всегда догадаешся, в каком случае надо что-то искать а в каком не надо.
З.Ы. Для меня совсем недавно стало откровением что в MSSQL"е нет даже примерного аналога offset"а или rownum(). (для мускуля: limit a,b). В результате adodb"шный лимит пришлось юзать да и тот тормозил (что естественно)
Ну, я думаю это понятно, что чем универсальней какая-либо библиотека - тем меньше оптимизаций под performance в ней будет. Т.е. вся абстракция сводится только к простейшим вещам. Если нужно писать более сложные запросы, к примеру с большим количеством JOIN"ов или SubSelect"ов - тогда, имхо, только руками. Если я не прав - поправьте...
p.s.
я всегда, по возможности, стараюсь жёстко зацепиться за платформу, и пользовать её по максимуму. (Правда и софт в основном пишу по заказу, под конкретную платформу)
Вообще, правильное решение тут — вынесение всего общения с базой на отдельный уровень модели. Тогда при возможном портировании с SQLLite на Oracle потребуется переписать только этот уровень. Пытаться же писать совместимые SQL -запросы, мне кажется, бесполезно — слишком большой бардак в диалектах.
Давид Мзареулян[досье] Странно звучит фраза, ведь если можно переписать уровень модели под другую базу не трогая остальные уровни, то значит у вас уже есть абстракция от особенностей БД и ничего не мешает сделать динамический выбор между реализациями.
Василий Свиридов[досье] Чем большое количество присоединений и подзапросов отличается от малого? Мне кажется ничем. И система, которая умеет строить одно присоединение, может строить и 10-ть.
2all: Вопрос в дизайне таких систем, достаточно сложно разработать гибкий дизайн, который позволит в полной мере использовать расширения той или иной СУБД, потому что иногда просто невозможно сделать приемлимую эмуляцию поведения на других БД. В таких случаях приходится жертвовать производительность и/или гибкостью.
Давид Мзареулян[досье] Где-то так, так как задача прикладного характера и не является отдельным законченным продуктом, а только инструментом, то разрабатываться и развиваться должна только в рамках конкретных проектов.
Закиров Руслан[досье] Отличается тем, что человек, имхо, сможет намного более эффективно соптимизировать сложный запрос, нежели скрипт. Хотя-бы потому, что человек может при этом учитывать схему базы и он знает, где можно жертвовать производительностью, а где - ну никак нельзя. (Моя аргументация правда начинает уходить от абстракции, так что на этом я закончу. А то оффтоп злостный пойдёт;))
База данных играет важную роль для каждого современного веб-приложения. Благодаря динамической природе веб-приложений сейчас, даже простейшие приложения требуют некоторых механизмов хранения, доступа и изменения данных (вот почему в Hostinger мы предлагаем для наших клиентов с премиум и бизнес аккаунтами). Естественно, поскольку важность баз данных стремительно растёт, реляционные системы управления базами данных или реляционные СУБД набирают свою популярность (Relational Database Management Systems – RDBMS)
SQL сервер также известен, как Microsoft SQL Сервер, появился значительно раньше, чем MySQL. Microsoft разработал SQL сервер в 80х, с обещанием разработать надёжную и расширяемую реляционную СУБД. Они остаются ядром качества SQL сервера по прошествии всех этих лет, и предоставляют незаменимое решение для крупномасштабного корпоративного программного обеспечения.
SQL сервер больше подходит для разработчиков, использующих.NET в качестве языка разработки, как конкурирующей связке PHP для MySQL. Это весьма логично, так как обе платформы принадлежать Microsoft.
Теперь, после краткого знакомства с системами, давайте посмотрим на несколько ключевых различий между MySQL и 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 сервером можно найти (англ.).
Выбор реляционной СУБД является важным для тех, кто только начинает разработку приложения. Люди, которые выбрали одну систему, редко позже переключаются на другую, а это означает, что важно сразу взвесить разные предложения и выбрать лучшее для вас.
В этом руководстве мы обсудили две наиболее распространенные реляционные СУБД – MySQL и Microsoft SQL сервер. Мы рассмотрели несколько ключевых различий между MySQL и SQL сервером, даже одного из которых может быть достаточно, чтобы сделать выбор.
В конечном счёте, выбор за вами. Как правило, если вы разрабатываете приложения среднего и малого размера и преимущественно используете PHP, переходите к 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; 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.
Для ознакомления с перечнем новых расширений, которые планируется добавить в сервер MySQL, а также с их приоритетностью, просмотрите список TODO по адресу http://dev.mysql.com/doc/mysql/en/TODO.html. В настоящем руководстве представлена последняя на данный момент версия списка TODO. См. также раздел MySQL и будущее (списки TODO).
Представьте себе город (назовем его А), в котором все говорят на одном языке. На нем строятся все бизнес-процессы, этот язык используется во всех формах общения. Словом, жители этого города понимают друг друга и исследуют окружающий мир только посредством этого языка. Если сменить язык в одном месте, все будут сбиты с толку.
А теперь представьте другой город Б, в котором все дома говорят на разных языках. Все по-разному взаимодействуют с миром, нет никакого «универсального» способа понимания или устойчивой организации общения. Если один что-то изменит, это ни на кого не повлияет.
Этот пример помогает проиллюстрировать одно из основных различий между 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.
Ниже представлены сильные стороны MySQL:
Ниже представлены сильные стороны MongoDB:
MySQL - отличный выбор для любого приложения, которому будет удобно пользоваться ее заранее определенной структурой и готовыми схемами. Например, это касается приложений, которые осуществляют переходы между нескольким записями (системы бухучета или управления инвентарем) или основаны на устаревших системах (им подойдет структура MySQL).
MongoDB, напротив, подойдет для бизнесов с быстрым ростом или для баз данных, в которых не используются определенные схемы. Точнее, если у вас не получается определить схему для БД или структуры постоянно меняются (как часто бывает с мобильными приложениями, аналитикой, работающей в реальном времени, системами менеджмента контента и т. д.), выбирайте MongoDB.
Прежде, чем приступить к статье, объяснющей разницу между SQL и MySQL , я поздравлю Вас с Новым годом , годом кролика. Желаю в Новом году Вам побольше удачи, побольше целеустремлённости и побольше упорства. Ведь главное в жизни - это достигать своих целей , а они достигаются только упорными людьми. Будьте упорны и настойчивы, и тогда в Новом году Вы будете победителем в любой сфере ! А теперь вернёмся к делу.
Я достаточно часто встречаю вопрос: "Какая разница между SQL и MySQL ", и я решил ответить на этот вопрос, несмотря на всю его абсурдность. Ведь с тем же успехом можно спросить: "Какая разница между сервером Apache и PHP ", но это почему-то никто не спрашивает.
В общем, отвечаю на вопрос. SQL - это язык запросов для управления СУБД (система управления базами данных ). А MySQL - это одна из таких СУБД . В частности, помимо MySQL существуют и другие СУБД : Oracle , MS SQL Server , PostgreSQL и много других. И чтобы работать (сделать выборку, вставить новую запись, добавить новую таблицу и так далее) с любой из этих СУБД необходим язык запросов, и таким языком и является SQL .
Надеюсь, я ответил на этот один из самых популярных вопросов среди новичков, которые только начинают заниматься базами данных. Хотя нет, Вы не новички, Вы молодцы ! Как показывает практика, люди не двигаются дальше HTML и CSS (редко JavaScript). И если Вы решили заниматься базами данных, то Вы уже герой! Так что Вы не новички, а просто начинающие познавать действительно важные и, в общем-то, сложные вещи. Удачи Вам в этом!