Миграция MySQL на PostgreSQL — какие функции, не видимые в коде SQL, будут важны?

• select count(*) from table;

  будет медленным, так как ему нужно прочитать всю таблицу. Нужны обходные пути, если вам нужно часто подсчитывать большие таблицы. Это необходимо для обеспечения управления многоверсионностью.

• В последней версии (8.3) нет неявного приведения к тексту, что означает, например,

  select 234 like '2%';

  выдаст ошибку. Вам понадобится явное приведение, например:

  select 234::text like '2%';

• Обновление — это удаление + вставка. Поскольку пространство, используемое удаленными строками, не освобождается сразу, если вы обновляете всю таблицу за одну транзакцию, вам потребуется удвоить пространство.

Postgresql — очень хорошая база данных, она вам очень понравится. У него есть несколько очень полезных функций, которых вам не хватает в других, даже коммерческих базах данных. Например, язык определения транзакционных данных или точки сохранения.

http://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL

Когда я переходил с MySQL на PostgreSQL, мне действительно мешало несколько вещей:

1) Код, записывающий в базу данных MySQL, был сломан, и подача мусора в базу данных реальной базой данных, у которой были внешние ключи, предотвратила бы. Будьте готовы найти "сюрприз" мусорных данных, как только вы добавите ссылочную целостность.

2) Индексы MySQL для строк нечувствительны к регистру! Если у вас есть первичный ключ для чего-то вроде имени пользователя, «Coryking» и «CORYKING» совпадают в соответствии с MySQL. В PostgreSQL они разные. Я не знал об этом, пока не начали появляться люди, которые регистрировали повторяющиеся имена пользователей, которые уже должны были быть в базе данных.

3) MySQL любит автоматически добавлять бессмысленные значения по умолчанию к столбцам, которые вы указываете как «NOT NULL». Например, если вы укажете VARCHAR(255) NOT NULL, это превратит определение этого столбца в «VARCHAR(255) NOT NULL DEFAULT ''».

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

Если вы не соответствуете стандарту SQL92 при типизации столбцов, вы будете сталкиваться с различиями в именах типов между ними.

Модификация переменных в запросе не работает в postgreSQL, например, это будет работать в MySQL, но не в postgreSQL (я не проверял это недавно, возможно, сейчас это работает).

SET @a:=1 SELECT ID,@a:=@a+1 FROM some_table;

Я также лично считаю, что postgreSQL лучше обрабатывает сложные запросы, включающие подзапросы и тому подобное (которых раньше избегало большинство пользователей MySQL).

Редактировать: О, и я чуть не забыл! Способ, которым postgreSQL хранит таблицы, совершенно отличается от того, как это делает MySQL. Это также может повлиять на ваши стратегии резервного копирования/восстановления.

Я не знаю, используете ли вы PHP или нет, но я обнаружил, что addlashes работает относительно хорошо для MySQL, но быстро бомбит в Postgres. Либо используйте pg_escape_string(), либо, что еще лучше, подготовленный оператор.

В зависимости от количества задействованных запросов (и если у вас есть кто-то, кто может это сделать), может быть целесообразно извлечь все запросы, адаптировать их по мере необходимости и запустить их на двух копиях существующей БД, на одной из которых работает mysql, а на другой — посгрел. Глядя на созданные журналы и сравнивая полученные данные, можно найти интересные подсказки. Первый шаг также может быть выполнен путем выполнения модульных тестов, ручного или скриптового тестирования приложения.

Основываясь на сравнении WikiVS, я обнаружил ряд интересных моментов, большинство из которых не совсем верно, например как: - подзапросы намного быстрее в Postgres, на самом деле это не проблема, но означает, что некоторые обходные пути могут быть удалены

Этот сайт действительно привел меня к списку Postgres Gotchas, в котором было больше подробностей о скорость count(*) и другая проблема с последовательным сканированием: Max и Min являются последовательными сканированиями. Вероятность того, что это повредит нашей работе, гораздо больше, чем что-либо еще, выявленное до сих пор. Однако эта статья включает обходной путь Max(col):

SELECT col FROM table ORDER BY col DESC LIMIT 1