SQLite, MySQL и PostgreSQL: сравниваем популярные реляционные СУБД
Авторизуйтесь
SQLite, MySQL и PostgreSQL: сравниваем популярные реляционные СУБД
Реляционные базы данных используются уже очень давно. Они стали популярными благодаря успешным реализациям реляционных моделей в системах управления, оказавшимся весьма удобными для работы с данными. В этой статье мы сравним три самые популярные реляционные системы управления базами данных (РСУБД): SQLite, MySQL и PostgreSQL.
Системы управления базами данных
Базы данных — это логически смоделированные хранилища любых типов данных. Каждая база данных, не являющаяся бессхемной, следует модели, которая задаёт определённую структуру обработки данных. СУБД — это приложения (или библиотеки), управляющие базами данных различных форм, размеров и типов.
Чтобы лучше разобраться в СУБД, ознакомьтесь с этой статьёй.
Реляционные системы управления базами данных
Реляционные системы реализуют реляционную модель работы с данными, которая определяет всю хранимую информацию как набор связанных записей и атрибутов в таблице.
СУБД такого типа используют структуры (таблицы) для хранения и работы с данными. Каждый столбец (атрибут) содержит свой тип информации. Каждая запись в базе данных, обладающая уникальным ключом, передаётся в строку таблицы, и её атрибуты отображаются в столбцах таблицы.
Отношения и типы данных
Отношения можно определить как математические множества, содержащие наборы атрибутов, отображающие хранящуюся информацию.
Каждый элемент, формирующий запись, должен удовлетворять определённому типу данных (целое число, дата и т.д.). Различные РСУБД используют разные типы данные, которые не всегда взаимозаменяемы.
Такого рода ограничения обычны для реляционных баз данных. Фактически, они и формируют суть отношений.
Популярные РСУБД
В этой статье мы расскажем о 3 наиболее популярных РСУБД:
SQLite
SQLite — это изумительная библиотека, встраиваемая в приложение, которое её использует. Будучи файловой БД, она предоставляет отличный набор инструментов для более простой (в сравнении с серверными БД) обработки любых видов данных.
Когда приложение использует SQLite, их связь производится с помощью функциональных и прямых вызовов файлов, содержащих данные (например, баз данных SQLite), а не какого-то интерфейса, что повышает скорость и производительность операций.
Поддерживаемые типы данных
Note: для получения более подробной информации ознакомьтесь с документацией.
Преимущества
Недостатки
Когда стоит использовать SQLite
Когда не стоит использовать SQLite
MySQL
MySQL — это самая популярная из всех крупных серверных БД. Разобраться в ней очень просто, да и в сети о ней можно найти большое количество информации. Хотя MySQL и не пытается полностью реализовать SQL-стандарты, она предлагает широкий функционал. Приложения общаются с базой данных через процесс-демон.
Поддерживаемые типы данных
Преимущества
Недостатки
Когда стоит использовать MySQL
Когда не стоит использовать MySQL
PostgreSQL
PostgreSQL — это самая продвинутая РСУБД, ориентирующаяся в первую очередь на полное соответствие стандартам и расширяемость. PostgreSQL, или Postgres, пытается полностью соответствовать SQL-стандартам ANSI/ISO.
PostgreSQL отличается от других РСУБД тем, что обладает объектно-ориентированным функционалом, в том числе полной поддержкой концепта ACID (Atomicity, Consistency, Isolation, Durability).
Будучи основанным на мощной технологии Postgres отлично справляется с одновременной обработкой нескольких заданий. Поддержка конкурентности реализована с использованием MVCC (Multiversion Concurrency Control), что также обеспечивает совместимость с ACID.
Хотя эта РСУБД не так популярна, как MySQL, существует много сторонних инструментов и библиотек для облегчения работы с PostgreSQL.
Сравнение MySQL и PostgreSQL с точки зрения разработчика
Аннотация
В статье представлен сравнительный анализ двух бесплатных свободных систем управления базами данных (СУБД): MySQL и PostgreSQL. Анализ ведётся с точки зрения использования этих СУБД в мало- и средненагруженных приложениях. Не рассматриваются вопросы масштабирования и оптимизации под проекты с многомиллионными аудиториями. Не приводятся данные сравнения производительности. Рассматриваются MySQL 5.1 и PostgreSQL 8.3.
Типы данных
Первое с чем приходится сталкиваться разработчику — это доступные типы данных. Проведём сравнение доступных типов данных.
Целые числа и числа с плавающей точкой
Я не буду указывать диапазоны возможных значений, однако укажу информационную ёмкость в байтах.
Как видно из таблицы, типы данных практически идентичны для двух СУБД. Различия состоят в том, что MySQL позволяет более детально использовать доступную память, но при этом работа с числами в символьном представлении ограничена 65 цифрами. Я не вижу ни одного практического применения числам с таким количеством знаков, потому можно считать что возможности MySQL и PostgreSQL в данном разделе идентичны.
Строки и данные
Размеры указываются в байтах. Не забывайте, что для одного символа UTF-8 может использоваться от 1 до 4 байт.
* ограничение вызвано максимальной длиной строки, равной 65535 байтам, но в реальности максимальная длинна гораздо меньше.
Из таблицы видно, что по ёмкости строковые типы данных в двух СУБД практически не различаются, и снова MySQL позволяет более детально контролировать формат хранения данных на жёстком диске. Однако эта гибкость MySQL вводит две небольшие проблемы на этапе проектирования: сумятицу в типах и размерах данных.
Чтобы не быть голословным приведу пример — хранение данных пользователя. Предположим, что нам потребовалось хранить о пользователе не только его имя, фамилию и отчество, но адрес и телефоны, да мало ли что мы можем предложить хранить пользователю в своём профиле. С точки зрения SQL для этого должны использоваться типы CHAR и VARCHAR. И вот тут в MySQL приходится решать какая максимальная длинна у фамилии, какая максимальная длинна у имени, какая максимальная длинна у адреса, ибо на всё про всё дано 65535 байт. В то же время в PostgreSQL мы просто указываем в качестве типа для всех столбцов таблицы VARCHAR, куда мы в случае необходимости можем уложить гораздо больше данных, чем нам позволяет MySQL. (Попрошу не предлагать использовать TEXT в MySQL для этих целей.)
Дата и время
Типы даты и времени для двух баз практически идентичны и проблем как правило не вызывают.
Нестандартные типы
Для желающих PostgreSQL предлагает целую группу типов данных для работы, которые напрочь отстутствуют в MySQL: массивы, структуры, типы для хранения IP и MAC адресов, и даже типы для хранения параметров геометрических фигур. Желающие могут самостоятельно ознакомиться с типами данных PostgreSQL.
UPD В MySQL, оказывается, есть типы данных для геометрических фигур подробности в комментариях
Выводы по типам данных
1) Типы данных, предлагаемые двумя СУБД, с функциональной точки зрения идентичны.
2) При помощи этих типов можно хранить данные в любой из СУБД, однако в MySQL разработчик вынужден на самом начальном этапе проектирования искуственно ограничивать длинну строковых данных, что не сказывается положительно на удобстве пользования системой.
3) Использование нестандартных типов в PostgreSQL позволяет довольно сильно упростить разработку, однако усложнит переход на другую СУБД.
4) MySQL позволяет точно контролировать структуру хранимых данных, однако при этом жертвуется удобством разработчика.
Возможности управления данными
Здесь я хочу сравнить две СУБД с точки зрения дополнительного функционала предлагаемого разработчику. Часть этого функционала включена в стандарт SQL.
Хранимые процедуры
Начнём с простейшего — хранимые процедуры. Грубо говоря, в MySQL вообще нет функционала хранимых процедур. Если выражаться более точно, то вообще они есть, но довольно условны. Так, например, при включённой репликации хранимые процедуры могут быть только readonly. Так что довольно популярная схема ограничения прав пользователя через хранимые процедуры вовсе не реализуема на MySQL.
Индексы и ключи
На этом фронте MySQL тоже не блещет своими возможностями. Ограничение в 1000 байт на размер ключа — куда это годится? Допустим, я разрешаю своим пользователям создавать учётные записи на любом языке (UTF-8). В качестве максимальной длинны логина я выбираю 512 символов. Так как логины должны быть уникальными, прихожу к выводу, что нужно наложить уникальный ключ на столбец, и, как выясняется, не могу, ибо ключ не вписывается в 1000 байт. Приходится идти на уступки и делать уникальность только по первым 333 символам. Кто не верит, может самостоятельно посмотреть на результат create table t( t varchar(512), key(t)) character set = utf8.
PostgreSQL такими комплексами не страдает, а просто делает уникальный ключ необходимого размера.
Проверка данных на этапе добавления
В стандарте SQL была предусмотрена инструкция CHECK, которая задаёт выражение, которому должны удовлетворять данные добавляемые в таблицу. В руководстве MySQL об этой инструкции сказано предельно просто «The CHECK clause is parsed but ignored by all storage engines.» Больше добавить мне к этому нечего, в постгре, как и ожидалось, всё в порядке.
Транзакции и внешние ключи
По умолчанию в MySQL для таблиц используется движок MyISAM, который не поддерживает ни транзакций ни внешних ключей. Это сложилось исторически и у такого подхода есть оправдание, если рассматривать работу с БД с точки производительности. Можно просто заметить, что, если вам нужны транзакции и внешние ключи, то использование storage engine InnoDB обязательно. Естественно в PostgreSQL транзакции и вешние ключи полностью функциональны.
Выводы
MySQL и PostgreSQL — это системы управления базами данных, перед которыми стоят разные задачи и стоит чётко понимать, в чём их разница. В качестве практических рекомендаций могу сказать, что MySQL показывает своё преимущество в области HighLoad, однако требует более внимательного подхода со стороны разработчика, а также накладывает довольно серьёзные ограничения на хранимые данные и на функциолнал СУБД.
Вобщем, для проектов не ориентированных на многомиллионную посещаемость, а также в академических целях я рекомендую использовать PostgreSQL. MySQL показывает своё преимущество на базах данных с большим количеством простых однотабличных запросов и требует к себе пристального внимания со стороны разработчкиа.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Сравнение производительности MySQL vs PostgreSQL
Реляционные базы данных использовались на протяжении длительного времени. Они стали популярными благодаря системам управления, которые реализуют реляционную модель настолько хорошо, что она является наилучшим способом работы с данными, особенно для критически важных приложений и служб.
MySQL существует достаточно давно и зарекомендовала себя как отличное решение, Postgresql пришла на рынок приблизительно в то же самое время, но предоставляет достаточно много интересных функций и возможностей, благодаря чему стремительно набирает популярность. В этой статье мы попытаемся выполнить сравнение MySQL vs Postgresql, сравним основные отличия этих систем и проведем несколько тестов для сравнения производительности этих баз данных.
Содержание
Основные характеристики баз данных
MySQL — свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems. [1]
PostgreSQL (произносится «Пост-Грэс-Кью-Эл») — свободная объектно-реляционная система управления базами данных (ORDBMS) (по-русски ОРСУБД или просто СУБД) основанная на POSTGRES, версии 4.2, которая была разработана в Научном Компьютерном Департаменте Беркли Калифорнийского Университета. [2]
| Параметры | MySQL | PostgreSQL |
|---|---|---|
| Краткое описание | Широко используемая свободная реляционная система управления базами данных | Широко используемая свободная реляционная система управления базами данных |
| Основная модель хранения данных | Реляционная база данных | Реляционная база данных |
| Дополнительная модель хранения данных | База данных типа Key/Value, документно-ориентированная база данных | База данных типа Key/Value, документно-ориентированная база данных |
| Вебсайт | www.mysql.com | www.postgresql.org |
| Документация | dev.mysql.com/doc | www.postgresql.org/docs/manuals |
| Разработчик | Oracle | PostgreSQL Global Development Group |
| Дата релиза | 1995 | 1996 |
| Текущая версия | 8.0.12, Июль 2018 | 10.5, Август 2018 |
| Лицензия | Открытое программное обеспечение | Открытое программное обеспечение |
| Облачное | Нет | Нет |
| Язык реализации | С++, C | C |
| Поддерживаемые операционные системы сервера | FreeBSD, Linux, Solaris, OS X, Windows | FreeBSD, Linux, Solaris, OS X, Windows, NetBSD, OpenBSD, HP-UX, Unix |
| Схема данных | Да | Да |
| Типизация | Да | Да |
| Поддержка XML | Да | Да |
| Поддержка вторичных индексов | Да | Да |
| SQL | Да | Да |
| API и другие методы доступа | Проприентарное нативное API, ADO.NET, JDBC, ODBC | Нативная С библиотека, потоковое API для больших объектов, ADO.NET, JDBC, ODBC |
| Поддерживаемые языки программирования | Ada, C, C#, С++, D, Delphi, Eiffel, Erlang, Haskell, Java, JavaScript (Node.js), Objective-C, OCaml, Perl, PHP, Python, Ruby, Scheme, Tcl | .Net, C, С++, Delphi, Java, Perl, PHP, Python, Tcl |
| Язык написания скриптов на стороне сервера | Да | Функции определенные пользователем |
| Триггеры | Да | Да |
| Методы разбиения | Горизонтальное разбиение, шардинг с MySQL Cluster или MySQL Fabric | декларативное разбиение (по диапазону или списку) начиная с PostgerSQL 10.0 |
| Методы репликаций | Master-Master, Master-Slave | Master-Slave |
| MapReduce | Нет | Нет |
| Концепции согласования | Немедленное согласование | Немедленное согласованиее |
| Параллелизм | Да | Да |
| Возможность хранения только в памяти | Да | Нет |
| Контроль доступа пользователей | Концепт пользователей с детальной авторизацией | Детальные права доступа в соответствии с SQL стандартом |
Критерии сравнения
Мы сравним скорость выборки из одной таблицы, обновления одной таблицы, скорость сортировки (ORDER BY) и группировки (GROUP BY) при выборке данных из одной таблицы, а также скорость вставки в таблицу и внутреннего объединения двух таблиц.
Выбор структуры таблиц и обоснование
Мы создадим две таблицы: first_table(rand_num int, some_data varchar(40)) и second_table(rand_num int, rand_group int, some_data varchar(40)). Атрибут some_data нам нужен просто для того, чтобы увеличить объем записи на диск, так что в него можно записывать любой текст. Атрибуты rand_num обеих таблиц будут содержать в себе случайные значения, так же как и атрибут rand_group второй таблицы. Тесты будут проводиться следующим образом:
1) сначала мы будем просто добавлять строки (до 400000 строк) в первую таблицу и замерять время добавления.
Когда же мы будем заполнять вторую таблицу (до 400000 строк), то каждый раз после добавления фиксированного числа строк (40000) мы будем проводить следующие измерения: 1) скорость внутреннего объединения первой и второй таблицы по атрибуту rand_num
2) скорость выборки всех данных из второй таблицы, сортируя их по атрибуту rand_num
3) скорость подсчета числа строк второй таблицы, принадлежащих одной группе (rand_group)
4) скорость выборки тех строк из первой таблицы, атрибут rand_num которых совпадает с атрибутом rand_num какой-либо строки второй таблицы
5) Скорость обновления атрибута some_data в строках первой таблицы. Но обновлять мы будем не все строки, а только те, которые удовлетворяют условию, описанному в п.4.
Все тесты мы проведем дважды: с индексированием атрибутов rand_num обеих таблиц и без индексирования. Отметим, что в данной серии тестов нас интересует производительность «из коробки», то есть сразу после установки обеих СУБД.
Результаты
С индексацией
Добавление. postgresql оказался быстрее с большим отрывом в 3,46 раза.
Внутреннее объединение. На небольшом количестве строк postgresql отрывается от mysql незначительно (в районе 25 процентов), но с увеличением размера второй таблицы преимущество postgresql становится более очевидным. При достижении второй таблицей максимального размера скорость объединения в postgresql уже в 2.8 раз выше. В среднем postgresql оказалась быстрее в 1,66 раза.
Сортировка. Postgresql быстрее на 60-100 процентов в зависимости от размера второй таблицы. В среднем postgresql быстрее в 2,04 раза.
Группировка. Сначала postgresql была быстрее в 4 раза, но с ростом второй таблицы преимущество сократилось до 1.6 раз. В среднем postgresql оказалась быстрее в 2,32 раза
Выборка. Postgresql справляется в среднем в 1,97 раза лучше.
Обновление. В postgresql время обновления данных растет более-менее линейно, чего совсем не скажешь о mysql, что говорит о разной реализации двух СУБД. При обновлении максимального числа строк postgresql справилась примерно в 2.5 раза лучше, при обновлении меньше числа строк отрыв становится гораздо существеннее. Postgresql справляется в среднем в 5,72 раза лучше.
Без индексации
И у postgresql, и у mysql скорость добавления выросла. Оно и понятно, ведь теперь не нужно строить дополнительные индексы. Тем не менее преимущество сохраняется у postgresql (в среднем в 4,44 раза).
Сортировка. Postgresql быстрее в среднем в 2 раза.
Группировка. Postgresql быстрее в среднем в 2,41 раза. Отмена индексирования практически никак не повлияла на скорость выполнения запросов с группировкой и сортировкой как у postgresql, так и у mysql. Это говорит о том, что алгоритмы сортировки и группировки в обеих СУБД от индексов не зависят.
Самым же неожиданным оказался тот факт, что отмена индексов в postgresql практически не сказалась даже на скорости выполнения объединения таблиц, а также выборки из первой таблицы и ее обновления. Хотя, казалось бы, в этих тестах нам важна скорость поиска по атрибуту rand_num, а индексирование как раз и должно было ускорить этот поиск. Для mysql же результаты тестирования объединения, выборки и обновления мы даже приводить не будем, так как уже при заполнении второй таблицы на 40000 строк на каждый запрос уходило более 400 секунд. Чего, собственно, изначально мы могли ожидать от обеих СУБД, а не только от MySQL.
Демонстрация работы
Установка баз данных
Подробный процесс установки этих баз данных можно увидеть в соответствующих статьях:
Заключение
Базы данных должны обязательно быть оптимизированы для окружения, в котором они будут использоваться. Исторически так сложилось, что MySQL ориентировалась на максимальную производительность, а Postgresql разрабатывалась как база данных с большим количеством настроек и максимально соответствующую стандарту. Но со временем Postgresql получила много улучшений и оптимизаций.
В большинстве случаев для организации работы с базой данных в MySQL используется таблица InnoDB, эта таблица представляет из себя B-дерево с индексами. Индексы позволяют очень быстро получить данные из диска, и для этого будет нужно меньше дисковых операций. Но сканирование дерева требует нахождения двух индексов, а это уже медленно. Все это значит, что MySQL будет быстрее Postgresql только при использовании первичного ключа.
Вся заголовочная информация таблиц Postgresql находится в оперативной памяти. Вы не можете создать таблицу, которая будет не в памяти. Записи таблицы сортируются по индексу, а поэтому их можно очень быстро извлечь. Для большего удобства можно применять несколько индексов к одной таблице.
В целом PostgreSQL работает быстрее MySQL, как показали тесты, примерно в 2 раза.
Сравнение MySQL и PostgreSQL
Реляционные базы данных использовались на протяжении длительного времени. Они стали популярными благодаря системам управления, которые реализуют реляционную модель настолько хорошо, что она является наилучшим способом работы с данными, особенно для критически важных приложений и служб.
MySQL существует достаточно давно и зарекомендовала себя как отличное решение, Postgresql пришла на рынок приблизительно в то же самое время, но предоставляет достаточно много интересных функций и возможностей, благодаря чему стремительно набирает популярность. В этой статье мы попытаемся выполнить сравнение MySQL vs Postgresql, сравним основные отличия этих систем, выясним как они работают и попытаемся понять какая система будет лучше для вашего проекта.
Системы управления базами данных
Базы данных предназначены для структурированного хранения и быстрого доступа к различным данным. Каждая база данных, кроме самих данных, должна иметь определенную модель работы, по которой будет выполняться обработка данных. Для управления базами данных используются СУБД или системы управления базами данных, именно к таким программам относятся MySQL и Postgresql.
Реляционные системы управления базами данных позволяют размещать данные в таблицах, связывая строки из разных таблиц и, таким образом, связывая разные, объединенные логически данные. Перед тем, как вы сможете сохранять данные, необходимо создать таблицы определенного размера и указать тип данных для каждого столбца. Столбы представляют поля данных, а сами данные размещены в строках. Обе системы управления базами данных, и MySQL vs Postgresql принадлежат к реляционным. Дальше мы рассмотрим подробнее чем отличаются обе программы. А теперь перейдем к более детальному рассмотрению.
Краткая история
MySQL
Разработка MySQL началась еще в 90х годах. Первый внутренний выпуск базы данных состоялся в 1995 году. За это время разработкой программы занимались несколько компаний. Разработка была начата шведской компанией MySQL AB, которую приобрела Sun Microsystems, которая, собственно перешла в собственность Oracle. На данный момент, начиная с 2010 года, разработкой занимается Oracle.
Postgresql
Разработка Postrgresql началась в далеком 1986 году в стенах Калифорнийского университета Беркли. Разработка длилась почти восемь лет, затем проект разделился на две части коммерческую базу данных IIlustra и полностью свободный проект Postrgesql, который разрабатывается энтузиастами.
Хранение данных
MySQL
Postgresql
Стандарт SQL
MySQL
MySQL поддерживает далеко не все новые возможности стандарта SQL. Разработчики выбрали именно этот путь развития, чтобы сохранить MySQL простым для использования. Компания пытается соответствовать стандартам, но не в ущерб простоте. Если какая-то возможность может улучшить удобство, то разработчики могут реализовать ее в виде своего расширения не обращая внимания на стандарт.
Postgresql
Возможности обработки
Из предыдущего пункта выплывают и другие отличия postgresql от mysql, это возможности обработки данных и ограничения. Естественно, соответствие более новым стандартам дает более новые возможности.
MySQL
При выполнении запроса MySQL загружает весь ответ сервера в память клиента, при больших объемах данных это может быть не совсем удобно. В основном по функциям Postgresql превосходит Mysql, дальше рассмотрим в каких именно.
Postgresql
Postgresql поддерживает использование курсоров для перемещения по полученным данным. Вы получаете только указатель, весь ответ хранится в памяти сервера баз данных. Этот указатель можно сохранять между сеансами. Здесь поддерживается построение индексов сразу для нескольких столбцов таблицы. Кроме того, индексы могут быть различных типов, кроме hash и b-tree доступны GiST и SP-GiST для работы с городами, GIN для поиска по тексту, BRIN и Bloom.
Postgresql поддерживает регулярные выражения в запросах, рекурсивных запросов и наследования таблиц. Но тут есть несколько ограничений, например, вы можете добавить новое поле только в конец таблицы.
Производительность
Базы данных должны обязательно быть оптимизированы для окружения, в котором вы будете работать. Исторически так сложилось что MySQL ориентировалась на максимальную производительность, а Postgresql разрабатывалась как база данных с большим количеством настроек и максимально соответствующую стандарту. Но со временем Postgresql получил много улучшений и оптимизаций.
MySQL
В большинстве случаев для организации работы с базой данных в MySQL используется таблица InnoDB, эта таблица представляет из себя B-дерево с индексами. Индексы позволяют очень быстро получить данные из диска, и для этого будет нужно меньше дисковых операций. Но сканирование дерева требует нахождения двух индексов, а это уже медленно. Все это значит что MySQL будет быстрее Postgresql только при использовании первичного ключа.
Postgresql
Вся заголовочная информация таблиц Postgresql находится в оперативной памяти. Вы не можете создать таблицу, которая будет не в памяти. Записи таблицы сортируются по индексу, а поэтому вы можете их очень быстро извлечь. Для большего удобства вы можете применять несколько индексов к одной таблице.
В целом PostgreSQL работает быстрее, за исключениям использования первичных ключей. Давайте рассмотрим несколько тестов с различными операциями:
Типы данных
Один из основных моментов обоих баз данных это поддерживаемые типы данных, которые вы можете использовать. Поскольку оба решения пытаются соответствовать синтаксису SQL, то они имеют похожие наборы, но все же кое-чем отличаются.
MySQL
MySQL поддерживает такие типы данных:
Postgresql
Поддерживаемые типы полей в Postgresql достаточно сильно отличаются, но позволяют записывать точно те же данные:
Как видите, типов данных в Postgresql больше и они более разнообразны, есть свои типы полей для определенных видов данных, которых нет MySQL. Отличие MySQL от Postgresql очевидно.
Разработка
Оба проекта имеют открытый исходный код, но развиваются по-разному. Развитие MySQL нравится далеко не всем. И в этом сравнение mysql и postgresql дает много отличий.
MySQL
База данных MySQL разрабатывается компанией Oracle и ходят слухи, что компания намерено тормозит развитие движка. Было создано очень много форков проекта, в том числе форк MariaDB от разработчика оригинальной MySQL. Но все же развитие остается медленным.
Postgresql
Как было сказано в начале статьи разработка началась в университете Беркли. Затем перешла в коммерческую компанию. Сейчас программа разрабатывается независимой группой программистов и советом нескольких компаний. Новые версии выпускаются достаточно активно и получают все новые и новые функции.
Выводы
В этой статье мы выполнили сравнение mysql и postgresql, рассмотрели основные отличия обоих систем управления базами данных и попытались понять что лучше postgresql или mysql. В общем результате лучшим по возможностях получается Postgresql, но он сложен и не везде его можно применять. MySQL проще, но не поддерживает некоторых интересных функций. А какую базу данных вы выберите для своего проекта? Почему именно ее? Напишите в комментариях!
На завершение видео с описанием возможностей и перспектив Postgresql:
