1. Вакансиях многих компаний довольно часто пишут требуемые знания через косую черту MySQL/PostgreSQL
На мой взгляд это совершенно разные базы данных и поэтому просто ставя между ними косую черту учитывая лишь во внимание написание схожих SQL запросов не совсем правильно. Все таки пару месяцев нужно для PostgreSQL, чтобы начать себя уверенно чувствовать в клиенте psql после MySQL.
Что я бы выделил на этапе компиляции из исходников этих двух БД,
1.1 PostgreSQL не имеет типы движков (MySQL — innodb, mysql, archive и т.д), но имеет кучу расширений, подобно PHP, которые можно дополнительно ставить, расширяя возможности. Создается впечатление, что PostgreSQL это своего рода каркас, который набиваешь функциональностью.
1.2 Разворачивание сервера MySQL сводиться лишь по сути к запуску сервера (systemctl start mysql.conf, service mysql start), тогда как в PostgreSQL нужно завести отдельного пользователя (в операционной системе) для запуска сервера, развернуть отдельно кластер (крутое слово, но по сути тоже самое, что и в MySQL — несколько баз данных на одном сервере)
1.3 Физическое указание расположения новых таблиц на диске (табличное пространство) на уровне SQL для PostgreSQL.
и т.д.
2. Различия в клиентах при запросах к БД — psql и mysql.
2.1 Что явно не хватает в MySQL, так это подобие команды \watch в psql, которая позволяет, указав секунды, повторять выполнение SQL запроса (аналог утилиты watch -n). Это обычно удобно для того, чтобы отслеживать как идет миграция (наполнение данных в таблицах)
select NOW() \watch 1;
2.2 В PostgreSQL по умолчанию все выполняемые запросы не отображают время исполнения, в отличие от MySQL, нужно дополнительно указывать команду \timing. Повторное выполнение команды отключает опцию. Такой прием часто встречается во многих настройках PostgreSQL, в отличие от MySQL, где это нужно писать более длинее. При этом, в PostgreSQL, когда смотришь справочную информацию, то рядом в круглых скобочках отображается текущее значение просматриваемой настройки. Очень удобно. Плохо только, что одним шрифтом теста идет, не сразу зрительно быстро воспринимается.
2.3 В PostgreSQL можно быстро просмотреть историю запросов из psql командой \s, тогда как в клиенте MySQL нужно использовать клавиши вверх/вниз задействую функционал readline библиотеки (либо смотреть историю команд отдельно от клиента mysql). Это часто нужно, когда тестируешь повторно запрос на использование индексов. Было бы удобней в PostgreSQL после набора \s вместо копирования запроса, набирать номер запроса, как это делается при profile в MySQL.
3. Есть много общих моментов, которые, к примеру в MySQL более удобны, а в PostgreSQL более сложны.
К примеру, вывод результата select, который не помещается по горизонтали. В обоих клиентах баз данных есть вертикальный вывод. Для MySQL достаточно добавить в конец запроса \G, тогда как в PostgreSQL в начале нужно выполнить \pset expanded. Когда нужно по быстрому просмотреть, вариант PostgreSQL на мой взгляд это не совсем удобно.
4. Особо интересный момент в PostgreSQL, в отличие от MySQL, это более тесная интеграция с bash оболочкой.
Можно из psql выполнять shell команды (наподобие как в vim редакторе :! pwd), сохранять в переменные результат и затем использовать в генерации SQL запросов. В MySQL это все можно тоже сделать, но более длинными и не всегда удобными путями.
5. PostgreSQL выделяется особой любовью к использованию переменных окружения (export) в отличие от MySQL.
Ты это чувствуешь сразу после того, как скомпилировал исходники и начинаешь “разворачивать” сервер, указывая путь к директории базы данных (-D или PGDATA).
На этом думаю, закончить свой беглый дилетантский обзор. Как я уже писал, целью является не позиционирование той или иной БД, а получение дополнительного опыта через сравнение. Для себя конкретно изучение PostgreSQL является дополнительным конкурентным техническим преимуществом.
Комментарии (8)
KlimovDm
08.06.2016 13:33Евгений, по пункту 1 я совершенно с вами согласен, но только в случае, если речь идет о профессии администратора БД. И mysql и postresql имеют такое огромное количество нюансов (особенно в части тонкой настройки), что можно книги писать. Как следствие — администратора лучше всего искать узкоспециализированного, но при этом все дальнейшие различия, описанные вами, по большому счету не различия вовсе, а так — мелкие особенности/удобства/неудобства.
Если же речь о программистах (они упоминаются вами во вступлении), то ситуация совсем другая. «SQL — он и Африке SQL» (с) Конечно, реализации языка отличаются, но переход с одной базы на другую для программиста не должен составлять большой проблемы, особенно если в своем коде он использует должный уровень абстракции. Это вопрос даже не времени, а текущей работы с документацией.
Но думаю, что вы писали все-таки с точки зрения администрирования БД, а не программирования.
bizzonaru
08.06.2016 20:33Согласен, но не совсем. Я рассматриваю сравнение с точки зрения программиста. Для прикладного уровня проекта в принципе да, не имеет значение какая база данных. Под прикладным я понимаю, взять простым запросом небольшое количество данных и нарисовать в табличной форме. Другой вопрос, когда такая таблица из разряда middle/big table, то тут уже нужно понимать как строится запрос на уровне базы данных, как хранятся данные.
KlimovDm
09.06.2016 10:02+1Это вроде бы так, но только на первый взгляд. Если программист работает с реляционными базами данных ему по большому счету должно быть все равно, как и в каком виде эти данные хранятся на стороне сервера. Есть общие подходы к проектированию БД, построению запросов, оптимизации запросов и т.п. и по большому счету эти подходы не зависят от размеров таблиц и количества данных (мы не говорим о bigdata/nosql). Нюансы начинаются в деталях (типы данных, встроенные функции или какая-нибудь темпоральная модель хранения/доступа к данным и т.д. и т.п.), но еще раз повторюсь — это не повод сортировать программеров на mysql/postgresql при рассмотрении вакансий на работу. Во всяком случае, я этого не делаю :)
TyVik
Насчёт пункта 3 есть \x auto — когда помещается будет колоночный вывод, в противном случае построчный. Вообще проще всего написать для себя файлик .psqlrc. У меня он примерно такого содержимого:
Psql по сравнению со всеми остальными подобными консольными утилитами просто небо и земля. Вот хорошая статья с примерами использования.
UUSER
Основное бесиво, это реакция mysql консоли на Ctrl+C, когда хочется начать использовать это :)
psqlrc забыл:
TyVik
Ох ты ж блин, огромное тебе спасибо!