conectar - Migrando de MySQL a PostgreSQL

sql mysql to 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, almacenará TB de datos, por lo que estoy ansioso por conocer las experiencias de mejoras / pérdidas de rendimiento, los principales obstáculos en la conversión de SQL y los procedimientos almacenados, etc.

Editar: Solo para aclararles a aquellos que han preguntado por qué no nos gustan las licencias 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

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).

Aquí están las cosas que nos mordieron:

1. MySQL no impone restricciones tan estrictamente como PostgreSQL.
2. Hay 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 estuvo en su lugar y probado, fue 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 automáticos en el directorio contrib son un buen punto de partida para su conversión, pero deberán ser tocados un poco por lo general.
• Recomiendo encarecidamente que utilice el nivel de aislamiento serializable como valor predeterminado.
• La herramienta pg_autodoc es buena para realmente ver sus estructuras de datos y ayudar a encontrar las relaciones que olvidó definir y aplicar.

Answer 2

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 usa sofisticadas cosas de MySQL, estarás bien.

Desde mi experiencia, nuestra base de datos MySQL (versión 3) no tiene Foreign Key ... PostgreSQL te permite tenerlos, así que tuvimos que cambiar eso ... y fue algo bueno y encontramos un 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.

Answer 3

Steve, tuve que migrar mi antigua aplicación, es decir, PgSQL-> MySQL. Debo decir que deberías considerarte afortunado ;-) Los errores comunes son:

• SQL es bastante similar al estándar de lenguaje, por lo que puede sufrir el dialecto de MySQL que ya conoce
• MySQL silenciosamente trunca varchar que exceden la longitud máxima, mientras que Pg se queja: solución rápida es tener estas columnas como ''texto'' en lugar de ''varchar'' y usar triggers para truncar líneas largas
• se usan comillas dobles en lugar de apóstrofos inversos
• Los campos booleanos se comparan utilizando operadores IS e IS NOT, sin embargo, es posible la INT (1) compatible con MySQL con = y <>
• no hay REEMPLAZAR, use el comando ELIMINAR / INSERTAR
• Pg es bastante estricto para imponer la integridad de las claves externas, así que no olvides usar ON DELETE CASCADE en las referencias
• si usa PHP con PDO, recuerde pasar un parámetro al método lastInsertId () - debe ser el nombre de la secuencia, que se crea normalmente de esta manera: [tablename] _ [primarykeyname] _seq

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