Migrando de MySQL a PostgreSQL

Question

Actualmente estamos utilizando MySQL para un producto que estamos creando, y estamos ansiosos por pasar a PostgreSQL tan pronto como sea posible, principalmente por razones de licencia.

¿Alguien más ha hecho tal movimiento? Nuestra base de datos es el alma de la aplicación y eventualmente almacenaremos TB de datos, por lo que estoy ansioso por conocer experiencias de mejoras/pérdidas de rendimiento, grandes obstáculos en la conversión de SQL y procedimientos almacenados, etc.

Editar: Just para aclarar a aquellos que han preguntado por qué no nos gusta la licencia de MySQL. Estamos desarrollando un producto comercial que (actualmente) depende de MySQL como un back-end de base de datos. Su licencia establece que debemos pagarles un porcentaje del precio de nuestra lista por instalación, y no una tarifa fija. Como inicio, esto es menos que atractivo.

Answer 1

Steve, tuve que migrar mi antigua aplicación, es decir, PgSQL-> MySQL. Debo decir, que debe considerarse afortunado ;-) precauciones comunes:

• SQL es realmente muy cerca de lengua estándar, por lo que puede sufrir el dialecto de MySQL que ya sabe
• MySQL trunca en voz baja que varchars exceda la longitud máxima, mientras que Pg se queja - solución rápida es tener estas columnas como 'texto' en lugar de 'varchar' y el uso de activadores para truncar las largas colas
• comillas dobles se utilizan en lugar de apóstrofes inversos
• campos booleanos se comparan usando Operadores IS y IS NOT, sin embargo compatible con MySQL INT (1) con = y <> es todavía posible
• existe ninguna es reemplazar, utilice DELETE/INSERT combinado
• Pg es bastante estricta en hacer cumplir la integridad de las claves foráneas, por lo que no se olvide de utilizar ON DELETE CASCADE en referencias
• si utiliza PHP con DOP, recuerde que debe pasar un parámetro a lastInsertId método() - que debe ser el nombre de secuencia, que se crea por lo general esta manera: [nombre de tabla] _ [primarykeyname] _seq

Espero que ayude al menos un poco. ¡Diviértete jugando con Postgres!

Answer 2

He hecho una conversión similar, pero por diferentes razones. Fue porque necesitábamos una mejor compatibilidad con ACID y la posibilidad de que los usuarios de la web vieran los mismos datos que podían a través de otras herramientas de DB (una identificación para ambas).

Estas son las cosas que nos mordían:

1. MySQL no impone restricciones tan estrictamente como PostgreSQL.
2. Existen diferentes rutinas de manejo de fechas. Estos deberán ser convertidos manualmente.
3. Cualquier código que no espere el cumplimiento de ACID puede ser un problema.

Dicho esto, una vez que estaba en su lugar y probado, era mucho mejor. Con el bloqueo correcto por razones de seguridad y uso simultáneo intenso, PostgreSQL tuvo un rendimiento mejor que MySQL. En los casos en que no se necesitaba bloqueo (solo lectura), el rendimiento no era tan bueno, pero aún era más rápido que la tarjeta de red, por lo que no era un problema.

Consejos:

• los scripts automatizados en el directorio contrib son un buen punto de partida para su conversión, pero necesitarán a tocar un poco por lo general.
• Recomiendo encarecidamente que utilice el nivel de aislamiento serializable de forma predeterminada.
• La herramienta pg_autodoc es buena para ver realmente sus estructuras de datos y ayudar a encontrar cualquier relación que se olvidó de definir y hacer cumplir.

Answer 3

Hicimos un movimiento de MySQL3 a PostgreSQL 8.2 luego 8.3. PostgreSQL tiene lo básico de SQL y mucho más, así que si tu MYSQL no utiliza sofisticadas cosas de MySQL, estarás bien.

Desde mi experiencia, nuestra base de datos MySQL (versión 3) no tiene clave externa ... PostgreSQL te permite tenerlos, así que tuvimos que cambiar eso ... y fue algo bueno y encontramos algún error .

La otra cosa que tuvimos que cambiar fue el conector de codificación (C#) que no era el mismo en MySQL. El MySQL fue más estable que el PostgreSQL. Todavía tenemos algunos problemas con el de PostgreSQL.