Миграция с MySQL на PostgreSQL

Стив, мне пришлось перенести мое старое приложение наоборот, то есть PgSQL->MySQL. Должен сказать, вы должны считать себя счастливчиком ;-) Общие ошибки:

• SQL на самом деле довольно близок к языковому стандарту, поэтому вы можете страдать от диалекта MySQL, который вы уже знаете.
• MySQL незаметно усекает varchars, которые превышают максимальную длину, тогда как Pg жалуется - быстрый обходной путь - иметь эти столбцы как «текст» вместо «varchar» и использовать триггеры для усечения длинных строк.
• двойные кавычки используются вместо обратных апострофов
• логические поля сравниваются с использованием операторов IS и IS NOT, однако MySQL-совместимый INT(1) с = и ‹> по-прежнему возможен
• REPLACE отсутствует, используйте комбинацию DELETE/INSERT
• Pg довольно строго следит за целостностью внешних ключей, поэтому не забывайте использовать ON DELETE CASCADE для ссылок.
• если вы используете PHP с PDO, не забудьте передать методу lastInsertId() параметр - это должно быть имя последовательности, которое обычно создается так: [tablename]_[primarykeyname]_seq

Я надеюсь, что это поможет хотя бы немного. Удачи, играя с Postgres!

Я сделал подобное преобразование, но по другим причинам. Это было связано с тем, что нам нужна была лучшая поддержка ACID и возможность предоставить веб-пользователям возможность видеть те же данные, что и с помощью других инструментов БД (один идентификатор для обоих).

Вот что нас укусило:

1. MySQL не применяет ограничения так строго, как PostgreSQL.
2. Существуют различные процедуры обработки даты. Их нужно будет конвертировать вручную.
3. Любой код, который не предполагает соответствия ACID, может быть проблемой.

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

Советы:

• Автоматизированные скрипты в каталоге contrib являются хорошей отправной точкой для вашего преобразования, но обычно к ним нужно прикасаться.
• Я настоятельно рекомендую использовать сериализуемый уровень изоляции по умолчанию.
• Инструмент pg_autodoc удобен для того, чтобы действительно увидеть ваши структуры данных и помочь найти любые отношения, которые вы забыли определить и применить.

Мы перешли с MySQL3 на PostgreSQL 8.2, а затем на 8.3. PostgreSQL имеет основы SQL и многое другое, поэтому, если ваш MYSQL не использует причудливые вещи MySQL, все будет в порядке.

По моему опыту, наша база данных MySQL (версия 3) не имеет внешнего ключа... PostgreSQL позволяет вам их иметь, поэтому нам пришлось это изменить... и это было хорошо, и мы нашли ошибку.

Еще одна вещь, которую нам пришлось изменить, — это коннектор кодирования (C#), который не был таким же в MySQL. Версия MySQL была более стабильной, чем версия PostgreSQL. У нас все еще есть несколько проблем с PostgreSQL.