Mysql или postgresql для разработки мобильного приложения. Сравнение MySQL и PostgreSQL. Так что же выбрать

Открытое ПО соответствующее стандарту SQL - PostgreSQL - бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой.

Большое сообщество - существует довольно большое сообщество в котором вы запросто найдёте ответы на свои вопросы

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

Расширения - существует возможность расширения функционала за счет сохранения своих процедур.

Объектность - PostrgreSQL это не только реляционная СУБД, но также и объектно-ориентированная с поддержкой наследования и много другого

Недостатки PostgreSql

Производительность - при простых операциях чтения PostgreSQL может значительно замедлить сервер и быть медленнее своих конкурентов, таких как MySQL

Популярность - по своей природе, популярностью эта СУБД похвастаться не может, хотя и присутствует довольно большое сообщество.

Хостинг - в силу выше перечисленных факторов иногда довольно сложно найти хостинг с поддержкой этой СУБД.

Когда использовать PostgreSql

Целостность данных - когда надежность и целостность данных - ваши требования, PostgreSQL будет, пожалуй, лучшим выбором

Сложные пользовательские процедуры - если вам необходимо использовать пользовательские процедуры, то PostgreSQL имеет встроенную поддержку для них

Интеграция - если в будущем вы планируете переход на платные СУБД, например Oracle, то сделать это с PostgreSQL будет довольно просто по сравнению с другими бесплатными СУБД

Сложная структура данных - по сравнению с другими открытими СУБД PostgreSQL предоставляет больше возможностей для создания сложных структур данных без необходимости жертовать какими либо аспектами.

Когда не следует использовать PostgreSql

Скорость - если быстрое чтение для вас единственный фактор, то стоит присмотреться к другим СУБД

Простая настройка - если вам не нужна целостность данных, соответствие ACID или сложные структуры данных, то настройка PostgreSQL может изрядно потрепать вам нервы

Репликация - если вы не готовы потратить время и энергию на то, что мог бы с легкостью сделать MySQL, то наверное проще было бы на нем и остаться.

NoSql системы управления базами данных

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

Существует довольно много различных моделей и функциональных систем для NoSQL баз данных:

Хранилище ключ-значение - Redis, MemcacheDB и т.д. (обычно хранят данные в памяти)

Распределённое хранилище (Column-oriented) - Cassandra, HBase и т.д (предназначены для очень больших объёмов данных).

Документо-ориентированные СУБД - MongoDB, Couchbase и т.д. (предназначены для хранения иерархических структур данных - документов)

БД на основе графов - OrientDB, Neo4J и т.д.

Чтобы лучше понять чем отличаются все эти типы СУБД, рассмотрим их.

SQL ,

Разработка веб-сайтов

• Перевод

Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day"16 Russia, до которой осталось всего два месяца.

Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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

Модель данных

PostgreSQL не просто реляционная, а объектно-реляционная СУБД. Это даёт ему некоторые преимущества над другими SQL базами данных с открытым исходным кодом, такими как MySQL, MariaDB и Firebird.

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

Структуры и типы данных

Существует обширный список типов данных, которые поддерживает Постгрес. Кроме числовых, с плавающей точкой, текстовых, булевых и других ожидаемых типов данных (а также множества их вариаций), PostgreSQL может похвастаться поддержкой uuid, денежного, перечисляемого, геометрического, бинарного типов, сетевых адресов, битовых строк, текстового поиска, xml, json, массивов, композитных типов и диапазонов, а также некоторых внутренних типов для идентификации объектов и местоположения логов. Справедливости ради стоит сказать, что MySQL, MariaDB и Firebird тоже имеют некоторые из этих типов данных, но только Постгрес поддерживает их все.

Давайте рассмотрим подробнее некоторые из них:

Сетевые адреса

PostgreSQL обеспечивает хранение разных типов сетевых адресов. Тип данных CIDR (бесклассовая маршрутизация интернет домена, Classless Internet Domain Routing) следует соглашению для сетевых адресов IPv4 и IPv6. Вот несколько примеров:

• 192.168.100.128/25
• 10.1.2.3/32
• 2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128
• ::ffff:1.2.3.0/128

Также для хранения сетевых адресов доступен тип данных INET, используемый для IPv4 и IPv6 хостов, где подсети являются необязательными. Тип данных MACADDR может использоваться для хранения MAC-адресов для идентификации оборудования, таких как 08-00-2b-01-02-03.

У MySQL и MariaDB тоже есть INET функции для конвертации сетевых адресов, но они не предоставляют типы данных для внутреннего хранения сетевых адресов. У Firebird тоже нет типов для хранения сетевых адресов.

Многомерные массивы

Поскольку Постгрес - это объектно-реляционная база данных, массивы значений могут храниться для большинства существующих типов данных. Сделать это можно путём добавления квадратных скобок к спецификации типа данных для столбца или с помощью выражения ARRAY. Размер массива может быть задан, но это необязательно. Давайте рассмотрим меню праздничного пикника для демонстрации использования массивов:

Создаем таблицу, у которой значения являются массивами CREATE TABLE holiday_picnic (holiday varchar(50) -- строковое значение sandwich text, -- массив side text , -- многомерный массив dessert text ARRAY, -- массив beverage text ARRAY -- массив из 4-х элементов); -- вставляем значения массивов в таблицу INSERT INTO holiday_picnic VALUES ("Labor Day", "{"roast beef","veggie","turkey"}", "{ {"potato salad","green salad","macaroni salad"}, {"chips","crackers"} }", "{"fruit cocktail","berry pie","ice cream"}", "{"soda","juice","beer","water"}");
MySQL, MariaDB, и Firebird так не умеют. Чтобы хранить такие массивы значений в традиционных реляционных базах данных, придется использовать обходной путь и создавать отдельную таблицу со строками для каждого из значений массива.

Геометрические данные

Геоданные быстро становятся основным требованием для многих приложений. PostgreSQL уже давно поддерживает множество геометрических типов данных, таких как точки, линии, круги и многоугольники. Один из этих типов – PATH, он состоит из множества последовательно расположенных точек и может быть открытым (начальная и конечная точки не связаны) или закрытым (начальная и конечная точки связаны). Давайте рассмотрим в качестве примера туристическую тропу. В данном случае туристическая тропа - это петля, поэтому начальная и конечная точки связаны, и, значит, мой путь является закрытым. Круглые скобки вокруг набора координат указывают на закрытый путь, а квадратные - на открытый.

Создаем таблицу для хранения троп CREATE TABLE trails (trail_name varchar(250), trail_path path); -- вставляем тропу в таблицу, -- для которой маршрут определяется координатами в формате широта-долгота INSERT INTO trails VALUES ("Dool Trail - Creeping Forest Trail Loop", ((37.172,-122.22261666667), (37.171616666667,-122.22385), (37.1735,-122.2236), (37.175416666667,-122.223), (37.1758,-122.22378333333), (37.179466666667,-122.22866666667), (37.18395,-122.22675), (37.180783333333,-122.22466666667), (37.176116666667,-122.2222), (37.1753,-122.22293333333), (37.173116666667,-122.22281666667)));
Расширение PostGIS для PostgreSQL дополняет существующие свойства геометрических данных вспомогательными пространственными типами, функциями, операторами и индексами. Оно обеспечивает поддержку местоположения и поддерживает как растровые, так и векторные данные. Оно также обеспечивает совместимость с множеством сторонних геопространственных инструментов (защищённых авторским правом и с открытым исходным кодом) для отображения, отрисовки и работы с данными.

Заметьте, что в MySQL 5.7.8 и в MariaDB, начиная с версии 5.3.3, были добавлены расширения типов данных для поддержки стандарта географической информации OpenGIS. Эта версия MySQL и последующие версии MariaDB предлагают хранение типов данных, аналогичное штатным геоданным Постгреса. Тем не менее, в MySQL и MariaDB значения данных сначала должны быть сконвертированы в геометрический формат простыми командами перед тем, как будут вставлены в таблицу. Firebird на данный момент не поддерживает геометрические типы данных.

Поддержка JSON

Поддержка JSON в PostgreSQL позволяет вам перейти к хранению schema-less данных в SQL базе данных. Это может быть полезно, когда структура данных требует определённой гибкости: например, если в процессе разработки структура всё ещё меняется или неизвестно, какие поля будет содержать объект данных.

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

В MySQL 5.7.8 и MariaDB 10.0.1 была добавлена поддержка встроенных объектов JSON. Но, хотя существует множество функций и операторов для JSON, которые теперь доступны в этих базах данных, они не индексируются так, как JSONB в PostgreSQL. Firebird пока что не присоединился к тренду и поддерживает объекты JSON только в виде текста.

Создание нового типа

Если вдруг так случится, что обширного списка типов данных Постгреса вам окажется недостаточно, вы можете использовать команду CREATE TYPE, чтобы создать новые типы данных, такие как составной, перечисляемый, диапазон и базовый. Рассмотрим пример создания и отправки запросов нового составного типа:

Создаем новый составной тип "wine" CREATE TYPE wine AS (wine_vineyard varchar(50), wine_type varchar(50), wine_year int); -- создаем таблицу, которая использует составной тип "wine" CREATE TABLE pairings (menu_entree varchar(50), wine_pairing wine); -- вставляем данные в таблицу при помощи выражения ROW INSERT INTO pairings VALUES ("Lobster Tail",ROW("Stag""s Leap","Chardonnay", 2012)), ("Elk Medallions",ROW("Rombauer","Cabernet Sauvignon",2012)); /* выборка из таблицы с использованием имени колонки (используйте скобки, отделяемые точкой от имени поля в составном типе) */ SELECT (wine_pairing).wine_vineyard, (wine_pairing).wine_type FROM pairings WHERE menu_entree = "Elk Medallions";
Поскольку они не являются объектно-реляционными, MySQL, MariaDB и Firebird не предоставляют такую мощную функциональность.

Размеры данных

PostgreSQL может обрабатывать много данных. Текущие опубликованные ограничения перечислены ниже:

В Compose [прим. пер.: организация, в которой трудится автор оригинальной статьи] мы автоматически масштабируем вашу инсталляцию, чтобы вам не приходилось волноваться о росте количества данных. Но, как известно любому администратору баз данных, стоит с опаской относиться к слишком большим и неограниченным возможностям. Мы советуем руководствоваться здравым смыслом при создании таблиц и добавлении индексов.

Для сравнения, MySQL и MariaDB печально известны ограничением размера строк в 65 535 байт. Firebird также предлагает всего лишь 64Кб в качестве максимального размера строки. Обычно объём данных ограничивается максимальным размером файлов операционной системы. Поскольку PostgreSQL умеет хранить табличные данные в множестве файлов меньшего размера, он может обойти это ограничение. Но стоит отметить, что слишком большое количество файлов может негативно сказаться на производительности. MySQL и MariaDB поддерживают большее количество столбцов в таблице (до 4,096 в зависимости от типа данных) и большие индивидуальные размеры таблицы, чем PostgreSQL, но необходимость превысить существующие ограничения Постгреса возникает лишь в крайне редких случаях.

Целостность данных

Постгрес стремится соответствовать стандарту ANSI-SQL:2008, отвечает требованиям ACID (атомарность, согласованность, изолированность и надежность) и известен своей ссылочной и транзакционной целостностью. Первичные ключи, ограничивающие и каскадные внешние ключи, уникальные ограничения, ограничения NOT NULL, проверочные ограничения и другие функции обеспечения целостности данных дают уверенность, что только корректные данные будут сохранены.

MySQL и MariaDB больше работают на то, чтобы соответствовать стандарту SQL с движками таблиц InnoDB/XtraDB. Теперь они предлагают опцию STRICT с использованием режимов SQL, которая устанавливает проверки корректности используемых данных. Несмотря на это, в зависимости от того, какой режим вы используете, недостоверные и даже урезанные без вашего ведома данные могут быть вставлены или созданы при обновлении. Ни одна из этих баз данных сейчас не поддерживает CHECK ограничения. Кроме того, у них существует множество особенностей в отношении ограничений ссылочной целостности по внешним ключам. В дополнение к вышесказанному, целостность данных может существенно пострадать в зависимости от выбранного движка хранения. MySQL (и fork MariaDB) не делают секрета из того, что променяли целостность и соответствие стандартам на скорость и эффективность.

Подводя итоги

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

Если вам кажется, что PostgreSQL не соответствует вашим потребностям, или вы предпочитаете “стрелять от бедра”, тогда вам стоит обратить внимание на NoSQL базы данных, которые мы предлагаем в Compose, или подумать о других SQL базах данных, которые мы упоминали. У каждой из них есть свои преимущества. Compose твёрдо уверен, что очень важно выбрать правильную базу данных для конкретной задачи… иногда это означает, что нужно выбрать несколько баз данных!

Хотите больше Постгреса?

А мне вот все лень сделать аналогичное. Только хотел проверить реальную базу на 300гигов. Поднять на скуле, на постгря, сделлать основные операции, типо проведения года, отмена проведения, тестирование и исправление со всеми галочками, бекапы, основные отчеты.
Но вот смотрю по заголовку вашей статьи и думаю - вау, круто... Теперь не надо париться, вот человек хороший сделал уже что то:) Открываю статью... Ан нет, все то же - бесполезные тесты, тема ни о чем, еще и в пдф, еще и аж 2 страницы... И даже без объяснения тестов... Ну хорошо, что они от гилева или нет? Т.е. в статье ничего не подняли, перенесли все в пдф? зачем? $m мало? Попросите - я вам перечислю. Но не надо таких вещей, с такими умными анонсами - делать так убого. Люди не правильно поймут.

Ну теперь по делу давайте:

Некоторые авторитетные товарищи прямо и недвусмысленно отказываются отвечать на вопрос: "Какая СУБД лучше?". Другие - менее авторитетные товарищи - говорят: "Только MS SQL Server принесет счастье в ваш дом". Третьи - уже совсем не авторитетные товарищи - несут в массы мнение об опенсорсе как единственном обладающем реальной производительностью железа ПО; а в продуктах Microsoft через строчку Sleep(random) понатыкано.

В целях выяснения - кто же прав - и была задумана эта статья. А поскольку каждое мнение должно быть аргументировано - было проведено сравнительное тестирование производительности для следующих продуктов:

Microsoft SQL Server 2008 R2
PostgreSQL для Linux
PostgreSQL для Windows

Круто:) Вот тут явно не хватает данных из пдф, так как если бы я тут увидел что вы все это разворачивали на XP, то я бы просто закрыл эту статью:) Далее веселее - виндовс x86, сервер 1с x64, эммм... ну ладно.

Если бы вы читали анонсы 1С, то вы бы увидели, что они ооооочень много нового сделали именно под MSSQL2012, т.е. вы заведомо сравнивали не пойми что с не пойми чем.

Про разные уровни изоляций систем - вы сказали вскольз, это улыбнуло. Давайте подумаем - почему 1С вешают на скуль в 99% случаях? верно - многопользовательский режим, блокировки и т.д., но вы сочли это мелкой задачей - на которую не стоит обращать внимание:)

З.Ы. Все хорошо, продолжайте в том же духе, просто вы делайте немного более глубокие тесты, описывайте более детально - что вы делаете и почему. Рассказывайте про свои мысли в каждом этапе. Без этого всего - вес этой статьи равен нулю.

З.З.Ы. Ставлю плюс авансом и надеюсь на более расширенный анализ.

З.З.З.Ы. Приведите в публикации аналогичные статьи отсюда, с других ресурсов, покажите что ваши данные сходятся с ними, или нет, и почему? Я надеюсь вы диплом сами писали, а не покупали? Если да, то просто берите структуру построения диплома - за основу.

Приведенное ниже сравнение проводилось в MySQL AB. Я старался быть как можно более точными и объективными, однако, зная MySQL, я не мог похвастаться таким же знанием возможностей PostgreSQL, поэтому в чем-то мог и ошибиться.

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

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

Большая же часть кода PostgreSQL написана множеством разработчиков, никак друг с другом не связанных. Не так давно разработчики PostgreSQL объявили о том, что у их команды наконец-то хватило времени на просмотр всего кода, вошедшего в состав очередной версии PostgreSQL.

Сравнение возможностей MySQL и PostgreSQL

MySQL обладает следующими преимуществами перед PostgreSQL:

· MySQL обычно намного превосходит PostgreSQL по скорости работы. Кроме того, в MySQL 4.0 реализован кэш запросов. Он позволяет во много раз увеличить скорость обработки запросов для сайтов, на которых преобладают неоднократно повторяющиеся запросы на чтение.

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

· MySQL работает в среде Windows лучше, чем PostgreSQL. MySQL Server запускается как настоящее (родное) Windows-приложение (в NT/2000/XP - сервис), в то время как PostgreSQL запускается в среде эмуляции, Cygwin. Доводилось слышать о недостаточной стабильности работы PostgreSQL в среде Windows, но самостоятельно эти сведения до сих пор проверить не мог.

· MySQL оснащен большим количеством API для других языков и поддерживается большим количеством существующих программ, нежели PostgreSQL.

· MySQL работает на высоконадежных промышленных системах 24/7 (включенных 24 часа в сутки 7 дней в неделю). В большинстве случаев никаких "чисток" в MySQL производить не требуется. PostgreSQL же пока что не может работать в таких системах, так как иногда приходится запускать VACUUM для освобождения занятого последствиями работы команд UPDATE и DELETE пространства и проводить статистический анализ, необходимый для достижения максимальной производительности PostgreSQL. Запускать VACUUM необходимо и после каждого добавления к таблице нескольких столбцов. На напряженно работающих системах VACUUM нужно запускать более часто, в худших случаях - по несколько раз в день. А ведь во время работы VACUUM (а ее работа может продолжаться часы, если база данных достаточно велика) база практически "мертва". Впрочем, в PostgreSQL версии 7.2 выполнение основных функций этой программы больше не приводит к блокировке базы, и пользователи могут продолжать нормально работать с ней. Новая команда VACUUM FULL берется за дело более серьезно: она, как и в старых версиях, блокирует таблицу и сжимает копию таблицы на диске.

· Книг о MySQL вышло значительно больше, нежели о PostgreSQL. Книги о MySQL выпустили издательства O"Reilly, SAMS, Que и New Riders. Все возможности MySQL детально описаны в документации, так как это является обязательным условием включения новых возможностей в код.

· MySQL обладает значительно более мощной реализацией ALTER TABLE.

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

· MySQL может работать с двумя поддерживающими транзакции обработчиками таблиц, а именно - InnoDB и BerkeleyDB. Так как все системы поддержки транзакций в разных условиях работают по-разному, это дает разработчику возможность найти наилучшее решение для условий, в которых будет работать его система. See section 7 Типы таблиц MySQL.

· Команда слияния таблиц MERGE предоставляет в ваше распоряжение уникальную возможность создать представление нескольких идентичных таблиц и работать с ними как с одной. Это особенно удобно для работы с журналами, разбитыми, например, по месяцам.

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

· В MySQL реализован полнотекстовый поиск.

· Имеется возможность работы с несколькими базами через одно соединение(разумеется, в зависимости от привилегий пользователя).

· Система MySQL с самого начала разрабатывалась в расчете на многопоточность, а PostgreSQL использует процессы. Переключение контекстов и доступ к общим данным несколькими потоками осуществляется значительно быстрее, нежели отдельными процессами. Таким образом MySQL Server в многопользовательских приложениях получает неплохое преимущество в производительности, а кроме того, таким образом MySQL Server удается значительно эффективней пользоваться преимуществами, предоставляемыми симметричными мультипроцессорными системами (SMP).

· В MySQL реализована значительно более мощная система привилегий, нежели в PostgreSQL. В то время как PostgreSQL обеспечивает лишь привилегии INSERT, SELECT и UPDATE/DELETE над базой или таблицей, MySQL предоставляет возможность определения полного набора разнообразных привилегий на уровне базы, таблицы и столбца. Кроме того, MySQL позволяет задавать привилегии для комбинаций хост/пользователь.

· В MySQL используется протокол связи между клиентом и сервером со сжатием данных, что увеличивает производительность системы в условиях низкоскоростных каналов связи.

· Все типы таблиц в MySQL (кроме InnoDB) реализованы в виде файлов (по одной таблице в файле), что значительно облегчает создание резервных копий, перенос, удаление и даже создание символьных ссылок между базами данных и таблицами, даже если сервер находится в нерабочем состоянии.

· Обновление (апгрейд) MySQL проходит совершенно "безболезненно". При модернизации MySQL нет нужды в копировании/восстановлении данных, что приходится делать при установке большинства обновлений PostgreSQL.

Ниже перечислены преимущества PostgreSQL по сравнению с MySQL на сегодняшний день.

Другие причины, по которым можно предпочесть PostgreSQL:

· В некоторых случаях PostgreSQL оказывается ближе к ANSI SQL.

· Работу PostgreSQL можно ускорить, выполняя код в виде хранимых процедур.

· При хранении географических данных R-деревья дают PostgreSQL преимущество перед MySQL (примечание: в MySQL версии 4.1 для таблиц MyISAM реализована поддержка R-деревьев).

· Команда разработчиков PostgreSQL, пишущих код для сервера, больше.

Недостатки PostgreSQL по сравнению с MySQL:

· VACUUM затрудняет использование PostgreSQL в постоянно работающих системах.

· Наличие только транзакционных таблиц.

· Значительно более медленная работа команд INSERT, DELETE и UPDATE.

Заключение

Единственные существующие на сегодня тесты, позволяющие сравнить MySQL Server и PostgreSQL, которые любой может загрузить и запустить, - это тесты из комплекта MySQL. И поэтому свой выбор я останавливаю на MySQL

Выбор между MySQL и PostgreSQL — это решение, которое должен принять каждый разработчик веб-приложений, который выбирает между различными Open-Source СУБД. Оба решения проверены временем и оба заслуживают пристального внимания. СУБД MySQL задумывалась как более быстрая но менее функциональная, в то время как разработчики PostgreSQL сосредоточились на большем количестве функционально полезных примочек чтобы как можно ближе соответствовать стандартам Oracle. MySQL очень популярен среди Web разработчиков по причине его высокой скорости и простоты использования. PosgreSQL менее популярен, так как удобен и просто только для тех разработчиков, которые ранее использовали Oracle или другие похожие базы данных. Но все скоростные характеристики MySQL по сравнению с PostgreSQL постепенно таят, так как с каждым обновлением PostgreSQL заметно прибавляет в скорости. Теперь рассмотрим эти две СУБД более пристально.

Архитектура

PostgreSQL уникальная СУБД с единым сервером хранения данных (СХД). MySQL имеет два слоя в своей архитектуре. Первый слой — это набор серверов хранения данных. По этому при сравнении обычно указывают какой именно сервер хранения данных MySQL использовался. Каждый сервер отличают и параметры быстродейстсвия и его функциональные возможности. Самый распространенный из них — InnoDB. Он отличается от остальных полной поддержкой модели ACID и высокой производительностью. Прямым конкурентом InnoDB считается MyISAM, который годится для обработки и хранения сравнительно небольших объемов данных, которые преимущественно считываются из БД, а не записываются. А также когда не критично отсутствие ACID. Приложения, которые работают с MySQL, могут одновременно использовать несколько СХД для обеспечения наилучшего набора функциональности и производительности.

Производительность

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

Ориентированность СУБД

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

Скоростные характеристики

PostgreSQL

PostgreSQL предоставляет функционал, который может увеличить производительность для некоторых видов SQL запросов. Из этих функций стоит выделить:
— частичное индексирование;
— сжатие данных;
— объем данных, хранимых в оперативной памяти;
— кэш запросов;

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

PostgreSQL поддерживает только один единственный СХД. Он входит в стандартную поставку PostgreSQL.

MySQL:ядро

MySQL 5.1 поддерживает 9 различных СХД:

1. MyISAM
2. InnoDB
3. NDB Cluster
4. MERGE
5. MEMORY (HEAP)
6. FEDERATED
7. ARCHIVE
8. BLACKHOLE

Однако, Federated и Blackhole не являются серверами «хранения» данных (например, Blackhole ничего не хранит). InnoDB разработан сторонней компанией InnoBase, которая была основана компанией Oracle. InnoDB поддерживает транзакции и занимает лидирующее место из всех поставляемых с MySQL серверов хранения данных.

MySQL планирует представить новые СХД Maria и Falcon в предстоящей версии 6.x. На них возложена задача заменить существующие движки MyISAM и InnoDB соответственно.

Существуют и другие СХД, разработанные сторонними компаниями и группами разработчиков. Наиболее популярные из них:

• SolidDB
• NitroEDB
• BrightHouse

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

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

MySQL также поддерживает сетевой протокол сжатия данных, который включается и выключается на стороне клиента (если конечно позволяет сервер). Данная функция сжимает все данные которые идут от сервера к клиенту.

MySQL:MyISAM

MyISAM это традиционный СХД для MySQL и предлагает лучшее соотношение производительности и функциональности для баз данных предназначенных преимущественно для выборки данных (select). MySQL MyISAM обрабатывает запросы на выборку быстрее чем PostgreSQL, если речь идет о простых запросах. MyISAM не поддерживает транзакций и внешних ключей.

MyISAM поддерживает лидирующий префикс сжатия для ключей и сжатых таблиц предназначенных только для чтения.

Системный таблицы MySQL всегда используют СХД MyISAM. Это сделано для того, чтобы исключить даже потенциальную возможность потери данных.

MySQL:InnoDB

InnoDB это полно функциональная ACID транзакционная система (сервер) хранения данных (СХД), которая использует технологию MVCC. Это хороший выбор для современных приложений MySQL.

InnoDB хранит данные с первичным ключами, так что поиск по первичным ключам происходит очень быстро. Данный подход очень полезен для физической оптимизации БД. В случае когда он не применим и дает низкую производительность, то явно его можно не использовать и тогда система создаст невидимый внутренний первичный ключ типа Integer(15) и будет проводить индексацию по нему.

InnoDB автоматически создает хэш индексы когда обрабатывает запросы на выборку (SELECT). Эта функция может быть отключена при необходимости. Некоторые процессы работают быстрее без этой функции.

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

Если InnoDB установлен как плагин к MySQL 5.1, он поддерживает сжатие таблиц налету. Вы можете использовать атрибуты ROW_FORMAT=COMPRESSED или KEY_BLOCK_SIZE в запросах CREATE TABLE и ALTER TABLE, чтобы дать команду InnoDB сжать каждую страницу в 1K, 2K, 4K, 8K или 16K байт.

Innobase Oy, это компания, которая занимается разработкой InnoDB. Она была куплена компанией Oracle в октябре 2005 года. С тех пор InnoDB все больше и больше заимствует у СУБД Oracle. А теперь, с покупкой компании MySQL компанией SUN эти и без того тесные взаимоотношения между Oracle и MySQL стали еще крепче. MySQL выходит на качественно новый уровень возможностей.

MySQL:NDB Cluster

NDB это высокопроизводительный преимущественно располагающиеся в Оперативной Памяти (RAM) СХД. Не индексируемые атрибуты могут сохраняться на жестком диске. Данные и логи также периодически синхронизируются на жесткий диск, чтобы избежать потери данных в случае внезапного «падения» кластера. NDB преимущественно используется в сфере телекоммуникаций, где аптайм и производительность в реальном масштабе времени критичны. NDB прозрачно собирает данные в фрагменты которые регулярно доставляет во все участки кластера. NDB использует внутреннюю синхронную репликацию чтобы записи были распространенны по меньшей мере на двух участках кластера прежде чем совершать фиксацию на жесткий диск. NDB также поддерживает автоматическое восстановление «упавших» элементов кластера (нодов). Из слабых сторон NDB стоит отметить очень плохую поддержку сложных запросов с использованием операторов JOIN.

В PostgreSQL похожих решений на данный момент просто нет.

MySQL:Archive

MySQL поддерживает сжатие на лету с версии 5.0, когда в дистрибутив попал СХД ARCHIVE. Archive — это СХД, который позволяет делать одновременно только 1 запись и множество чтений. Разработан специально для архивных баз данных, где запись в БД осуществляется гораздо реже и преимущественно одним источником данных. Сила сжатия достигает 90%. Archive не поддерживает индексы. В версии MySQL 5.1 Archive может работать с несколькими разделами (партициями).

MySQL:Falcon

Falcon это ACID транзакционный СХД, который был разработан самой MySQL. В данный момент он находится в зачаточном состоянии и доступен для тестирования в бета-ветке MySQL 6.0. Falcon поддерживает сжатие данных налету. Данные, сохраненные в таблицах Falcon, сжимаются на жестком диске, но в оперативной памяти хранятся не в сжатом ввиде. Сжатие происходит автоматически, когда данные синхронизируются на жесткий диск.

MySQL:Maria

Maria это ACID СХД, который был разработан Монти Вайденисом (Monty Widenius) и командой разработчиков MySQL.

Мультпроцессность

Исторически сложилось, что MySQL разрабатывалась и оптимизировалась под однопроцессорные системы. PostgreSQL в этом смысле смотрится гораздо симпатичнее. Чем больше ядер в системе, тем PostgreSQL работает быстрее, чего о MySQL сказать трудно.

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

Ассинхронный Ввод/Вывод

PostgreSQL полностью поддерживает асинхронный API для использования в клиентских приложениях. Данная возможность позволяет увеличить производительность в некоторых случаях до 40%. В MySQL отсутствует поддержка асинхронного режима. Но существует несколько драйверов, которые предоставляют эту возможность. Например MySQL драйверы для perl и ruby.

COUNT(*)

Транзакционные версионные СУБД, которые построены на модели MVCC, например такие как PostgreSQL и InnoDB, выполняют COUNT(*) очень медленно в сравнении с не транзакционными СХД или транзакционными не версионными СХД, например такими как MyISAM. MyISAM в MySQL использует сканирование индексов для обработки COUNT(*) и также кэширует полученный результат, данный подход гораздо эффективнее. PostgreSQL и InnoDB требуют полного сканирования таблицы на предмет учета всех видимых полей. MVCC-совместимые СХД выполняют операцию COUNT(*) данным способом потому, что MVCC сохраняет информацию о видимости или не видимости транзакции в данных самой записи (ROW). Во всех MVCC-совместимых СХД кэширование результатов операции COUNT(*) приведет к возврату некорректных данных. PostgreSQL Count() работает медленнее чем COUNT(*) в InnoDB.

Тесты производительности

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

Модель ACID

ACID следует понимать как Atomicity, Consistency, Isolation и Durability (Валентность, Последовательность, Изоляция и Длительность). Данная модель используется для обеспечения целостности данных средствами СУБД. Многие СУБД достигают соглашений ACID путем использования транзакций.

PostgreSQL и MySQL использующий InnoDB, Cluster и Falcon СХД полностью соответствуют всем принципам и канонам модели ACID.
Возможности

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

Простота использования

Готча (Gotcha) — это функция или функции которые работают так как описаны но не так как ожидалось (http://sql-info.de/mysql/gotchas.html). Поклонники PostgreSQL настаивают на том, что MySQL имеет больше готчей чем PostgreSQL.

В последних версиях MySQL представила пользователям различные режими работы SQL, которые совместимы с различными стандартами SQL и позволяют легко разобраться в MySQL тем, кто с MySQL никогда не работал.

Insert Ignore / Replace

MySQL поддерживает операторы ‘INSERT IGNORE’ и ‘REPLACE’ которые вставляют запись если ее не существует и ничего не делают в другом случае или заменяют текущую запись соответственно.

PostgreSQL не поддерживает ничего из выше перечисленного и советует использовать сохраненные процедуры для достижения такого эффекта. Однако существует одно «НО». В одно и тоже время может быть вставлено только одно значение. Данное условие накладывает серьезные ограничения на производительность и вызывает определенные сложности. INSERT IGNORE и REPLACE обрабатывают вставку нескольких значений и их запись симпатичнее чем процедура.

Еше одна полезная запись в MySQL: INSERT … ON DUPLICATE UPDATE также напрочь отсутствует в PostgreSQL и для реализации своими руками требует написания сохраненных процедур, которые могут обрабатывать только 1 запись в один момент времени.

Ограничители

Обе СУБД PostgreSQL и MySQL поддерживают ограничители Not-Null, Unique, Primary Key и Foreign Key. Однако MySQL не поддерживает ограничение Check когда PostgreSQL поддерживает его уже довольно продолжительное время.

Таблицы InnoDB поддерживают проверки внешних ключей. Для остальных СХД MySQL разбирает и игнорирует FOREIGN KEY и REFERENCES в директиве CREATE TABLE.

Для движков MySQL не поддерживающих внешние ключи могут быть применены тригеры.

Значения по умолчанию

PostgreSQL позволяет для колонок использовать в качестве значения по умолчанию любую функцию помеченную как IMMUTABLE или STABLE. В MySQL, на данный момент, лишь функция Now() может быть использована как значение по умолчанию для колонки.

Сохраненные процедуры

И PostgreSQL и MySQL поддерживают сохраненные процедуры.

Главный язык запросов в PostgreSQL — PL/pgSQL, он похож на PL/SQL в Oracle. PostgreSQL также поддерживает SQL:2003 PSM сохраненные процедуры также как и другие популярные языки программирования Perl (PL/Perl), Python (PL/Python), TCL (PL/Tcl), Java (PL/Java) и даже C (PL/C).

MySQL следует синтаксису SQL:2003 для сохраненных процедур, который также используется в IBM DB2.

MySQL поддерживает другие языки программирования сохраненный процедур с помощью плагинов. Из самых популярных стоит отметить Java, Perl, XML-RPC.

Триггеры

И PostgreSQL и MySQL поддерживают триггеры. Триггеры в PostgreSQL могут выполнять любые пользовательские функции из любого процедурного языка.

Триггеры в MySQL активируют только SQL запросами. Они не активируются изменениями в таблицах, которые делаются при помощи MySQL API и не выполняют никаких SQL запросов.

PostgreSQL также поддерживает правила (RULES), которые позволяют оперировать над синтаксисом запросов и могут делать некоторые операции проще, чем традиционный механизм триггеров.

Синтаксис для определения триггеров в PostgreSQL не так силен как в MySQL. PostgreSQL требует раздельного определения функции с специальным типом возвращаемого значения.

Репликация и Высокая Доступность

Репликация — это механизм СУБД дублировать свои данные для резервных копий а также для зеркалирования на другие сервера для обеспечения высокой стабильности. PostgreSQL и MySQL оба поддерживают репликации:

PostgreSQL

PostgreSQL поддерживает репликацию на уровне подключаемых модулей. Существует несколько модулей, которые позволяют осуществлять репликацию данных СУБД PostgreSQL:
— PGCluster
— Slony-I
— DBBalancer
— pgpool
— PostgreSQL table comparator
— SkyTools
— Sequoia
— Bucardo
— Mammoth Replicator
— Cubercluster
— GridSQL (shared-nothing)

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

Слабые места репликации в PostgreSQL

Slony-I наиболее широко используемый инструмент для репликации данных в PostgreSQL и является прямой противоположностью встроенному механизму репликации данных в MySQL. Во первых он использует SQL и триггера для сбора данных для репликации по всему серверу. Этот подход координально медленнее чем родной способ репликации данных в MySQL, который использует бинарный режим обработки БД. Во вторых Slony-I не придатен для использования в огромных кластерах, так как потребление ресурсов равно квадрату используемых серверов для репликации данных.

2 сервера: MySQL: 2 = 2 PostgreSQL: 2*2^2 = 8
4 сервера: MySQL: 4 = 4 PostgreSQL: 2*4^2 = 32
12 серверов: MySQL: 12 = 12 PostgreSQL: 2*12^2 = 288.

Пока Slony-I адекватен для высокой доступности с использованием двух серверов. Slony-I очень тяжело администрировать.

Bucardo написан на языке Perl и интенсивно использует триггеры PL/PGSQL и PL/PERLU.

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

MySQL

MySQL поставляется с поддержкой асинхронной репликации данных. Начиная с версии 5.1, MySQL поддерживает два формата репликации. SBR отслеживает SQL запросы, которые вносят изменения в БД, в специальный бинарный логфайл, на который подписаны все дочерние сервера. Соответственно при изменениях в главной БД, все остальные БД получают копии данных. RBR отслеживает инкрементальные изменения записей и записывает их в бинарный лог-файл, из которого получают данные все дочерние БД. RBR используется автоматически, когда выполняется определенный запрос в главной БД. Некоторые СХД как NDB, Falcon и в некоторых случаях InnoDB для репликации используют только RBR.

Начиная с версии 6.0 MySQL поддерживает полу-синхронную репликацию в которой мастер подтверждает получение хотя бы одной дочерней БД до возврата из процедуры комита данных. Этот метод позволяет уменьшить до минимума потери данных, особенно в больших кластерах.

Типы данных

PostgreSQL не поддерживает unsigned integer, но имеет более широкую поддержку типов данных в аспектах соответствия стандартам, базовый логический тип Boolean, определение пользовательских типов данных, встроенные типы данных.

PostgreSQL позволяет колонкам таблиц быть определенными как мультиразмерный массив с изменяемой длинной. Массивы могут быть любого встроенного или пользовательского типа, enum или композитного типа. Но вот массивы доменов пока не поддерживаются.

MySQL не имеет типа данных IP Адрес, который присутствует в PostgreSQL но для преобразований из и в IPV4 используются функции INET_ATON() и INET_NTOA(). В БД хранится как Integer.

Подзапросы

MySQL и PostgreSQL поддерживают подзапросы. В MySQL подзапросы появились недавно и требуют сильной доработки по части производительности. В PostgreSQL подзапросы доведены практически до совершенства.

Расширенное индексирование

Расширенное индексирование позволяет СУБД выполнять запросы с гораздо более высокой скоростью. И MySQL и PostgreSQL поддерживают расширенное индексирование.

Множественные индексы.

MySQL поддерживает множественные индексы для каждой таблицы в отдельности и может использовать один индекс для одной таблицы. PostgreSQL поддерживает множественные индексы для каждого запроса в отдельности.

Полнотекстовые индексы.

MySQL идет с поддержкой полнотекстового поиска, но поиск может быть использован только на СХД MyISAM. Также MySQL поддерживает внешние модули для организации полнотекстового поиска — Sphinx Fulltext Search Engine. Данный плагин добавляет поддержку полнотекстового поиска для СХД InnoDB.

PostgreSQL начиная с версии 8.2 имеет в своем распоряжении полнотекстовый поиск в модуле tsearch2. Начиная с версии 8.3 модуль tsearch2 интегрирован в ядро PostgreSQL.

Частичное индексирование

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

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

Порционирование

MySQL поддерживает несколько форм горизонтального порционирования:
— RANGE
— LIST
— HASH
— KEY
— Композитное порционирование используя RANGE или LIST с HASH или KEY

PostgreSQL поддерживает только RANGE и LIST. HASH порционирование поддерживается с помощью внешних функций. Также PostgreSQL поддерживает композитные решения.

Лицензирование

PostgreSQL распространяется по лицензии BSD, в которой отмечены пункты Free Software Definition и Open Source Definition и стандарт Copyfree.

MySQL доступен по лицензии GNU General Public License, в которой также отмечены пункты Free Software Definition и Open Source Definition но не по стандарту Copyfree. А это значит что если будет издан продукт, в котором используются исходники MySQL вам придется либо заплатить за коммерческую копию MySQL AB либо открыть исходные коды для общего пользования.

Разработка

MySQL владеет и спонсирует одна профилирующая компания MySQL AB. Правда теперь она является частью Sun Microsystems, которая в свою очередь была приобретена компанией Oracle. MySQL AB держит копирайты и исходники MySQL.

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

MySQL — это ПРОДУКТ с открытым исходным кодом.
PostgreSQL — это ПРОЕКТ с открытым исходным кодом.

Происхождение названия

Когда был создан стандарт ANSI SQL, его автор сказал, что официально SQL произносится как «ess queue ell». Имена и MySQL и PostgreSQL отражают в своих именах этот стандарт. MySQL официально произносится как «my ess queue ell». Однако многие произносят MySQL как «my sequel».

Так как MySQL является собственностью компании MySQL AB, то компания была вынуждена сохранить копирайты на имя своего детища и по этому название скорее всего останется неизменным.

PostgreSQL произносится как «пост гресс ку элл». Название сформировано из старого названия Postgres (так называлась СУБД на базе которой был создан PostgreSQL) и SQL. Некоторые люди называют Постгрескуэл как пиджискуэл (pgsql). Ходят слухи, что PostgreSQL будет переименован назад в Postgres. На данный момент идут активные дебаты по этому поводу.

Популярность

MySQL широко известен и применяется в большинстве открытых (open-source) разработок по всему миру. Наиболее часто используется СХД MyISAM. И с уверенностью можно сказать, что MySQL самая популярная СУБД для вебразработок по всему миру.

Основаниями для такой популярности служит то, что MySQL легче использовать, чем другие СУБД, в частности PostgreSQL. Это утверждение бытует уже много лет. Но фактически несколько лет назад PostgreSQL произвел серьезные изменения в своей структуре и может по праву считаться более легким в использовании нежели MySQL. Но вопрос по прежнему открыт. Что же выбрать? MySQL или PostgreSQL?

Версия статьи