Passer de MySQL à PostgreSQL-astuces, astuces et gotchas?

j'envisage de passer de MySQL à PostgreSQL.

Quels sont vos trucs et astuces pour travailler avec PostgreSQL?

que doit faire un MySQLer?

Voir aussi: Combien est différent PostgreSQL MySQL?

Voir aussi: Migrer de MySQL à PostgreSQL

Note-Je ne pense pas que ce soit un double. En particulier, le type de réponses sont très différentes et les réponses ici ont beaucoup plus de détails de mise en œuvre, ce qui est ce que je cherchais

33
demandé sur Community 2009-04-21 15:18:24

6 réponses

vient de passer par là moi-même, et bien je le suis toujours...

  • sensible à la casse du texte
  • manque de INSERT IGNORE et REPLACE
  • Casting explicite nécessaire presque partout
  • Pas de backticks
  • LOAD DATA INFILE ( COPY est étroit, mais pas assez près)
  • changer autoincrement en SERIAL
  • Bien que la mauvaise forme dans MySQL, dans Postgres, un INNER JOIN sans une clause ON ne peut pas se produire, utiliser CROSS JOIN ou similaire
  • COUNT(*) peut être fou lent
  • les Bases de données sont codés avec les jeux de caractères, pas de tables
  • vous pouvez avoir plusieurs bases de données, avec plusieurs schémas (MySQL a vraiment juste une base de données et plusieurs schémas)
  • le partitionnement est différent
  • MySQL interval vs. Postgres interval (pour les intervalles de temps)
  • colonne implicite renommer, Postgres nécessite AS
  • ne peut pas mettre à jour plusieurs tables en même temps dans Postgres
  • Postgres fonctions sont puissantes. Il n'y a donc pas de CALL proc(); ; réécrire proc() en fonction et SELECT proc(); .
50
répondu rfusca 2010-08-20 13:53:54

il va être une tâche énorme que vous aurez à tester votre code-base entière - chaque requête simple, n'importe où, pour

  • syntaxe
  • comportement Correct (c'est à dire renvoie les mêmes résultats)
  • Performance-p. ex. y a-t-il des régressions / améliorations de performance, et pouvez-vous les gérer?
  • traitement des erreurs - ils ne se comportent pas de la même façon dans des conditions d'erreur, peut-être votre code se fiait-il sur les codes d'erreur spécifiques

du point de vue opérationnel, vous aurez besoin de regarder:

  • Sauvegarde/restauration
  • utilisation de L'espace disque
  • utilisation de la mémoire
  • migration de données unique - pourrait être une tâche fastidieuse et fastidieuse
  • plan de Restauration pour si elle échoue
  • surveillance-comment surveillez-vous votre MySQL, et ces méthodes peuvent-elles être adapté
  • (le cas échéant) - réplication

vous aurez certainement à faire des quantités importantes de tests de performance avant d'envisager un tel déplacement.

ces coûts rendent le passage à une base de données différente trop coûteux pour la plupart des applications non triviales. Considérez les avantages très soigneusement contre les vastes, énormes coûts de faire tout ce qui précède.

I serait surpris si vous prenez moins de trois mois, dans une application non triviale, au cours de laquelle vous ne serez pas en mesure de continuer le développement régulier.

9
répondu MarkR 2009-04-21 15:56:25

Vous pouvez essayer de PostgreSQL pièges qui contient le plus de questions d'intérêt commun. En général, la documentation PostgreSQL est assez bonne aussi, alors gardez-la sous votre oreiller.

aussi, conversion de MySQL en PostgreSQL sur le wiki pgsql.

8
répondu janneb 2009-04-21 11:34:09

j'ai trouvé ce script qui va se connecter à votre base de données MySQL et votre base de données PostgreSQL et juste transférer le contenu. Ça a fonctionné comme un charme pour moi.

https://github.com/philipsoutham/py-mysql2pgsql

installé par

$ pip install py-mysql2pgsql

Exécuter

$ py-mysql2pgsql

dans n'importe quel dossier, et il créera un fichier de configuration de modèle pour vous (mysql2pgsql.yml) que vous pouvez modifier et saisissez les données de vos bases de données.

j'ai dû installer argparse pour qu'il fonctionne.

$ pip install argparse

lorsque les détails de votre base de données sont remplis, exécutez-le à nouveau

$ py-mysql2pgsql

dans le même dossier que le fichier de paramètres, et paf, vous avez terminé. Il n'a rien imprimé à l'écran, mais ma base de données a été entièrement copiée par la suite.

6
répondu Dahlo 2012-04-05 07:58:39

avant de convertir, réglez votre MySQL sur ANSI-strictness en démarrant le serveur avec: -- transaction-isolation=SERIALISABLE --sql-mode=ANSI

assurez-vous que vous n'utilisez pas les tables MyIsam.

MySQL permet beaucoup de conversions qu'il ne devrait pas; pg exigera un plâtre.

vos procs, fonctions et déclencheurs stockés devront être réécrits. pg vous donne un choix de langues pour ceux-ci, mais vous devez installer le langues; ce N'est pas aussi convivial que MySQL.

pg ne permettra dans une liste select que les colonnes qui sont dans un groupe par ou sont des agrégats; MySQL trichera en sélectionnant la première valeur dans le groupe si vous faites cela.

MySQL ajoute un tas d'extensions: l'opérateur Non-equal peut être != comme en C, il permet '&&' comme synonyme de 'et', '||' pour 'OU' etc. En particulier, pg utilise '| / ' pour signifier caténation de chaîne.

En gros, pg est strictement ANSI, pas MySQL. Je suggère fortement d'obtenir votre MySQL à une conformité ANSI aussi stricte que possible avant de passer à pg, puis de vérifier les avertissements lorsque vous exécutez vos applications.

5
répondu tpdi 2009-04-21 11:36:38

mis à part la structure mobile de la base de données, où vous ne pouvez pas éviter les réglages manuels...

la méthode la plus fiable de transfert de données (tableau par tableau, à condition que les structures soient les mêmes):

mysql --default-character-set=utf8 -e "SELECT * FROM mytable" > mytable.txt

psql
\copy mytable from '/path/to/mytable.txt' WITH NULL AS 'NULL';

ont essayé toutes les autres approches récemment (comme mysqldump avec des tonnes d'options + sed etc.), mais rien n'a fonctionné comme nice comme cela.

cette approche permet également à certains flexibilité lorsque la structure est modifiée en cours de route - il suffit d'écrire un SELECT approprié.

1
répondu Ivka 2013-03-04 20:25:43