Хотел бы пояснить своё мнение по соответствию стандарту. Если принять, что фраза «PostgreSQL является SQL-совместимым (SQL:2011)» на самом деле означает «PostgreSQL соответствует SQL:2011 нестрого, в некоторой степени», то в этом же самом смысле можно сказать и «MySQL является SQL-совместимым (SQL:2011)». Ведь соответствует же. Нестрого, в некоторой степени, хоть и в меньшей, чем PostgreSQL. Поэтому я считаю, что с терминами нужно аккуратнее, это важный вопрос.
На мой взгляд, нельзя соответствовать стандарту «нестрого». Стандарту можно либо соответствовать, либо нет. Поэтому утверждение «PostgreSQL is SQL-compliant (SQL:2011)» из оригинальной статьи ложно. А утвеждение из официальной документации «PostgreSQL supports most of the major features of SQL:2011» истинно. С другой стороны, утверждения «It is fully ACID compliant» и «Its SQL implementation strongly conforms to the ANSI-SQL:2008 standard» отсюда снова ложные.
Про упоминания названия стандарта — это претензия относилась не к данной статье, а моей ссылке. Если я правильно понял.
Ну не учёл человек, что к нему строгие эксперты с Хабра придут. Иначе бы он конечно по всей форме доложился. С ссылками, цитатами и названиями стандарта.
А я кстати совершенно не спорю с утверждением «PostgreSQL лучше соответствует SQL стандарту, чем MySQL». Я кстати уже об этом писал.
Но это же совсем не то, что PostgreSQL сообщество любит говорить. PostgreSQL сообщество любит говорить «PostgreSQL является SQL-совместимым» («PostgreSQL is SQL-compliant» в оригинале). Это враньё. И rdruzyagin это знает, но старательно это враньё переводит.
А я здесь никаким сравнением MySQL и PostgreSQL не занимаюсь. Это у вас какой-то каскадный триггер на ключевые слова сработал. Я говорю, что два утверждения из статьи не соответствуют действительности и привожу примеры. PostgreSQL сообщество любит тиражировать такие байки.
По поводу оффтопа — я могу вам рассказать о гораздо более серьёзных проблемах в MySQL, чем каскадные триггеры. Собственно, я это уже делал на Хабре и в докладах. Но действительно оффтоп же.
Источник правды там нормальный. Я знаком с человеком лично — это ходячая энциклопедия по SQL стандарту. Это человек, которого можно разбудить ночью, и спросить про любой произвольный аспект SQL стандарта. И он подробно расскажет, с примерами и аспектами реализации в разных СУБД. А ещё этот человек автор книг по SQL стандарту. Просто вы в статье пытаетесь прочитать то, чего там нет. Статья утверждает, что MySQL в некоторых вещах лучше соответствует SQL стандарту. А я статью привёл потому, что там действительно есть примеры несовместимости SQL стандарта и PostgreSQL.
Да, я говорил про hash индексы, естественно, просто закоротило провода. Но на Хабре нельзя редактировать комментарии. И т. д.
Я перечитал это сообщение несколько раз, но так и не понял, что вы хотели сказать. Что я не прав, то есть по ссылке есть примеры несоответсвия PostgreSQL стандарту SQL? Или что я не прав, то есть по ссылке нет примеров несоответствия PostgreSQL стандарту SQL? Или смешная третья опция?
Про bitmap индексы всё просто: они не журналируются в WAL. Поэтому для них durability не существует. И репликации тоже.
Во времена MySQL 3.23 в PostgreSQL не было репликации вообще ни в каком виде (ни встроенной, ни внешней), не было FTS вообще ни в каком виде, вакуум нужно было запускать строго вручную, не было контрольных сумм, не было UPSERT, не было ни единой компании, которая предлагала бы коммерческую поддержку. Это так, для справки.
Ну это не про PostgreSQL vs MySQL, а про BSD vs GPL. И этому спору в обед сто лет. Точно такие же споры велись лет 15 назад про FreeBSD vs Linux. «Самая либеральная лицензия», «принадлежит сообществу», «кто угодно может сделать проприетарный форк» и далее по списку.
BSD даёт больше прав потребителям кода, GPL даёт больше прав авторам. Я за большие права для авторов. А всех желающих поспорить отправляю к Столлману.
Да я даже не знаю, с чего начинать. Наверное, с того, что MemSQL построен на совершенно других концепциях, чем MySQL или другие популярные РСУБД. Единственная совместимость с MySQL, которую обещают — это клиент-серверный протокол. Ни совместимости по файлам данных, ни по функциональности между MySQL и MemSQL нет и никогда не было. Я собственно впервые слышу версию о том, что MemSQL основан на MySQL. Откуда такая информация?
MemSQL не основан на MySQL, как написано в статье, а совершенно независимая и проприетарная СУБД, совместимая с MySQL по протоколу. Две большие разницы, как по мне.
Привет, Илья! Да, это то, что мы успели обсудить за 5 минут общения на Percona Live. Но список отличий этими двумя пунктами не исчерпывается. Я собираюсь развернуто поговорить на эту тему на DevConf: http://devconf.ru/ru/offers/offer/127
Приходите/приезжайте. Думаю, достаточно интересный рассказ получится.
Этому мнению недавно исполнилось 7 лет. И я по-моему уже отвечал на него, но попробую ещё раз. Oracle хочет, чтобы MySQL оставалась лидирующей СУБД для Web. С платным продуктом добиться этой цели невозможно. Просто потому, что бесплатных проектов, желающих занять эту нишу хоть пруд пруди. MongoDB, MariaDB и PostgreSQL спят и видят, чтобы MySQL стал платным. Но нет.
На мой взгляд, нельзя соответствовать стандарту «нестрого». Стандарту можно либо соответствовать, либо нет. Поэтому утверждение «PostgreSQL is SQL-compliant (SQL:2011)» из оригинальной статьи ложно. А утвеждение из официальной документации «PostgreSQL supports most of the major features of SQL:2011» истинно. С другой стороны, утверждения «It is fully ACID compliant» и «Its SQL implementation strongly conforms to the ANSI-SQL:2008 standard» отсюда снова ложные.
Про упоминания названия стандарта — это претензия относилась не к данной статье, а моей ссылке. Если я правильно понял.
Но это же совсем не то, что PostgreSQL сообщество любит говорить. PostgreSQL сообщество любит говорить «PostgreSQL является SQL-совместимым» («PostgreSQL is SQL-compliant» в оригинале). Это враньё. И rdruzyagin это знает, но старательно это враньё переводит.
По поводу оффтопа — я могу вам рассказать о гораздо более серьёзных проблемах в MySQL, чем каскадные триггеры. Собственно, я это уже делал на Хабре и в докладах. Но действительно оффтоп же.
Да, я говорил про hash индексы, естественно, просто закоротило провода. Но на Хабре нельзя редактировать комментарии. И т. д.
Про bitmap индексы всё просто: они не журналируются в WAL. Поэтому для них durability не существует. И репликации тоже.
Меня тут сейчас заминусуют как обычно, но это всё неправда, конечно:
И это навскидку, наверняка можно накопать ещё примеров. Просто никто этим никогда не занимался. Все больше любят громкие красивые утверждения.
Во времена MySQL 3.23 в PostgreSQL не было репликации вообще ни в каком виде (ни встроенной, ни внешней), не было FTS вообще ни в каком виде, вакуум нужно было запускать строго вручную, не было контрольных сумм, не было UPSERT, не было ни единой компании, которая предлагала бы коммерческую поддержку. Это так, для справки.
Теперь планирую на основе докладов сделать статьи на Хабре, где разбирать всё подробнее, чем в докладах.
BSD даёт больше прав потребителям кода, GPL даёт больше прав авторам. Я за большие права для авторов. А всех желающих поспорить отправляю к Столлману.
Приходите/приезжайте. Думаю, достаточно интересный рассказ получится.