вторник, 1 февраля 2011 г.

PostgreSQL vs MySQL

Небольшая заметка о том, почему PostgreSQL круче MySQL:

  • лучшая работа со подзапросами
  • схемы - часто очень удобно пользоваться как пространствами имен
  • чеки - позволяют дополнительно проверять данные перед сохранением
  • рулы - позволяют создавать обновляемые вьюхи
  • каскадное удаление при дропе таблицы или колонки - мускуль попросит удалять все сначала ручками
  • наследование таблиц
  • триггеры: временное отключение, триггерные функции, табличные триггеры. Временное отключение бесценно при накатывании миграций, триггерные функции можно использовать повторно
  • отсутствие кучи ограничений внутри триггеров и функций типа обновить таблицу на которой был вызван триггер и т.п.
  • сиквенсы - позволяют реализовать паттерн "поле идентификации"
  • внешние ключи: составные, отложенная проверка. Отложенная проверка полезна, когда не нужно проверять целостность во время транзакции и можно отложить это до конца транзакции
  • индексы по выражению, составные, частичные и хэш индексы, возможность задавать порядок, конкурентное создание индекса
  • сам язык SQL мощнее - включает исключения и много чего другого
  • можно писать на любом языке (Java, C, PHP и др)
  • библиотека полнотекстового поиска и куча других полезных библиотек, возможность создавать собственные библиотеки
  • рекурсивные запросы
  • запросы к XML данным
  • возможность задавать порядок вывода null полей
  • масштабирование на многоядерных системах (мускуль в этом отношении мертвый)
  • транзакционный DDL - возможность делать миграции схемы БД в транзакции.
  • простое добавление и удаление колонок. В постгре по сути изменяются метаданные таблицы, поэтому все происходит очень быстро в не зависимости от размера таблицы; а в мускуле удаление колонки может днями идти блокируя все на своем пути
  • умный оптимизатор запросов
  • Строгая типизация, пользовательские типы, массивы, полноценые булевы

Последняя версия 9.0 получила поддержку репликаций "из коробки", так что исчезла последняя причина оставаться на MySQL.

Если у кого-нибудь еще что-то есть, добавляйте в каменты :)

14 комментариев:

  1. хэш индексы в mysql присутствуют.
    можно писать на любом языке (Java, C, PHP и др)
    А что в mysql это не так??

    ОтветитьУдалить
    Ответы
    1. Имеется в виду написание встроенных процедур и пр. на этих языках, а НЕ только на SQL

      Удалить
  2. - запросы к xml данным
    http://dev.mysql.com/tech-resources/articles/xml-in-mysql5.1-6.0.html

    - лучшая работа со подзапросами
    - умный оптимизатор запросов
    Слишком голословно, где примеры? и лучше брать не MySQL а MariaDB и заскриншотить планы запросов.

    ОтветитьУдалить
  3. > можно писать на любом языке (Java, C, PHP и др)
    имеются ввиду процедуры. У MySQL не знаю про такую возможность

    ОтветитьУдалить
  4. Каскадное удаление это Foreign Keys, в InnoDB это есть и всё пекрасно каскадно удаляется, если правильно составлена схема.

    Тригеры тоже есть. Пусть не так круто как в PostgreSQL, но есть.

    И вообще - PostgreSQL это Enterprise, а MySQL это WEB. Отсюда и разница в продвинутом функционале, разные назначения. Вы глянте на Drizzle - оттуда вообще убрали тригеры, процедуры и кучу прочего, сконцентрировавшись на производительности и оптимизаторе.

    ОтветитьУдалить
  5. > Каскадное удаление это Foreign Keys, в InnoDB это
    > есть и всё пекрасно каскадно удаляется, если
    > правильно составлена схема.

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

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

    Про оптимизацию и скорость. По-моему легче писать триггеры для нормализации БД, чем следить за этим из приложения. Даже, не говоря про какую-то сложную бизнес-логику, просто кол-во фотогрфий у пользователя считать - это быстрее чем отдельным запросом считать COUNT(*).

    Да, PostgreSQL сложнее в освоении, но это действительно профессиональный инструмент, причем доступный каждому.

    ОтветитьУдалить
  6. >Сравнили бы еще с MS SQL
    К сожалению, опыта работы с оным не имею, но сравнивать его можно только с PostgreSQL, как равным

    ОтветитьУдалить
  7. В довесок:
    * Массивы
    * Расширяемость: типы, операторы, методы доступа
    * Индексы GiST и GIN, легко адаптируемые под разные задачи

    ОтветитьУдалить
  8. Postgre ближе по духу к Oracle, с ним и интереснее сравнивать.
    Не стоит воспринимать как чистую монету, но все же:
    http://oracle.axoft.ru/catalog/PSQLvsOracle.php

    ОтветитьУдалить
  9. каскадное удаление в mysql работает без проблем

    ОтветитьУдалить
  10. bugman, что-то там уж крайне предвзято, и, зачастую, совсем не конкретно. Маркетинговые материалы, не более.

    ОтветитьУдалить
  11. >сиквенсы - позволяют реализовать паттерн "поле идентификации"

    Там есть такое понятие как автоинкремент

    ОтветитьУдалить
  12. haughtymaster, сиквенсы более мощный и гибкий механизм - он позволяет использовать единый диапазон идентификации (сквозной) для разных сущностей

    ОтветитьУдалить