Сведения о вопросе

Kirushaa

12:20, 22nd August, 2020

Теги

Переход с MySQL на PostgreSQL

Просмотров: 498   Ответов: 3

В настоящее время мы используем MySQL для продукта, который мы создаем, и стремимся перейти на PostgreSQL как можно скорее, в первую очередь по причинам лицензирования.

Кто-нибудь еще сделал такой шаг? Наша база данных-это жизненная сила приложения и в конечном итоге будет хранить TBs данных, поэтому я очень хочу услышать об опыте работы improvements/losses, основных препятствий в преобразовании SQL и хранимых процедурах и т. д.

Edit: просто чтобы разъяснить тем, кто спрашивал, почему нам не нравится лицензирование MySQL. Мы разрабатываем коммерческий продукт, который (в настоящее время) зависит от MySQL в качестве бэк-энда базы данных. В их лицензии говорится, что мы должны платить им процент от нашей прейскурантной цены за установку, а не фиксированную плату. Как стартап, это менее чем привлекательно.



  Сведения об ответе

Chhiki

15:30, 19th August, 2020

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

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

Надеюсь, это хоть немного поможет. Есть много удовольствия, играя с Postgres!


  Сведения об ответе

fo_I_K

22:46, 2nd August, 2020

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

Вот те вещи, которые нас укусили:

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

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

Чаевые:

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


  Сведения об ответе

#hash

09:20, 29th August, 2020

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

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

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


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться