Я уже писал об этом раньше, но у меня нет причин менять этот совет:
MySQL легче начать использовать.
Хорошие инструменты пользовательского интерфейса. Быстрее, если вы не используете ACID. Более терпимый к неверным данным. Автоинкрементные столбцы так же просты, как и автоинкремент. Разрешения не так привязаны к файловым системам и пользователям ОС. Установить разделитель проще, чем использовать PG «цитирование со знаком доллара» при написании хранимого процесса. В MySQL вы подключаетесь ко всем базам данных, а не только к одной.
Postgres (PG) в большей степени соответствует стандартам, но уродливее и сложнее, особенно с точки зрения пользовательского интерфейса. Раньше требовалось ручное вакуумирование, и на самом деле обеспечивает ссылочную целостность (что является отличной вещью, которая может быть болью в заднице). Автоинкремент гораздо более гибкий, но требует последовательности (которую можно замаскировать, используя последовательный порт), и подождите, что за OID?
Так что, если вы на самом деле не знаете или не очень заботитесь о базах данных, достоверности данных, соответствии ACID и т. Д., Но вам небезразлична простота и скорость, вы склонны использовать MySQL.
Слишком многие (не все, но многие) «веб-программисты» много знают о «web 2.0», PHP или Java, но мало знают о теории или практике баз данных («индекс? Что это?») , Они склонны рассматривать базу данных как просто причудливую хеш-таблицу или пакет данных, и, действительно, такую, которая нигде не может быть динамически изменяемой или прощающей, как хеш-таблица.
Для этих людей MySQL - потому что до 5.0 она не была на самом деле СУБД, а во многих отношениях - нет, это находка. Это «быстрее», чем у конкурентов, и не «тратит время» на «эзотерические» базы данных, которые веб-программист не хочет, не понимает и не видит в значении.
Для кого-то, имеющего опыт работы с базами данных, с другой стороны, MySQL - это минное поле: вещи, которые должны работать (сложные представления, групповые запросы, порядковые запросы в групповых циклах), могут работать или могут, если вам повезет, аварийно завершить работу сервера, или если вам не повезло, просто дайте результаты с неверными данными.
Я провел дни, работая над некоторыми из этих вещей, по общему признанию, сложными, не чрезвычайно сложными взглядами и групповыми образами.
И MySQL на самом деле не быстрее. Если вы используете таблицы InnoDb для ACID (или просто потому, что при количестве строк более 30 миллионов, таблицы MyISAM имеют тенденцию становиться дрянными), то прямой выбор из одной таблицы, вероятно, быстрее, чем в PG. Но добавьте в соединения, и PG вдруг значительно быстрее. (MySQL особенно плох при внешних соединениях.)
В итоге: если для вас база данных является сумкой, если вы никогда не намереваетесь заниматься анализом данных или отчетами, если вы в основном заинтересованы в том, чтобы обслуживать большие фрагменты текста с небольшими связями или обновлениями - то есть, если вы используете базу данных для блога, MySQL - отличный выбор.
Но если вы на самом деле управляете данными, если вы понимаете, что данные живут дольше и ценнее для бизнеса, чем интерфейсные программы и бизнес-правила среднего уровня, если вам нужны функции реальной базы данных, используйте PG .
«Веб-программист», который решил, что все его структуры таблиц могут быть автоматически сгенерированы Hibernate (или каким-либо другим ORM), смотрит на это и говорит: «слишком сложно» и «я держу пари, что сложное означает большую стоимость и меньшую скорость» и поэтому он идет с MySQL.
Как я уже сказал, PG намного лучше, и я ненавижу гадать с причудливыми ошибками MySQL, и я думаю, что общая производительность PG, вероятно, лучше, чем MySQL для любого даже немного сложного запроса.
Но MySQL заставляет вещи выглядеть (обманчиво) простыми, поэтому многие люди, которые не совсем разбираются в дизайне баз данных, считают, что MySQL - отличный выбор.
Используйте PG. Он последовательный, надежный, соответствует стандартам, он быстрее (даже умеренно) сложных запросов, не полностью сбивает ваш график со странными ошибками.