Migración de MSSQL a PostgreSQL:lo que debe saber

Como sabrá, Microsoft SQL Server es un RDBMS muy popular con licencias altamente restrictivas y un alto costo de propiedad si la base de datos es de un tamaño significativo o es utilizada por una cantidad significativa de clientes. Proporciona una interfaz muy fácil de usar y fácil de aprender. Esto ha resultado en una gran base de usuarios instalados.

PostgreSQL es la base de datos de código abierto más avanzada del mundo. La comunidad de PostgreSQL es muy fuerte y mejora continuamente las funciones existentes e implementa nuevas funciones. Según el rango de popularidad de db-engine, PostgreSQL fue el DBMS del año 2017.

¿Por qué migrar de MS SQL Server a PostgreSQL?

1. MS SQL Server es una base de datos propietaria de Microsoft, mientras que PostgreSQL es desarrollado y mantenido por una comunidad global de desarrolladores de código abierto. Si el costo es un problema, definitivamente debería optar por PostgreSQL. Puede consultar los precios aquí.
2. PostgreSQL es un motor de base de datos multiplataforma y está disponible para Windows, Mac, Solaris, FreeBSD y Linux, mientras que SQL Server solo se ejecuta en el sistema operativo Windows. Como sabrá, PostgreSQL es de código abierto y completamente gratuito, mientras que el costo del servidor MSSQL depende de la cantidad de usuarios y el tamaño de la base de datos.
3. Licencias flexibles de código abierto y fácil disponibilidad de proveedores de nube pública como AWS, Google Cloud, etc.
4. Benefíciese de los complementos de código abierto para mejorar el rendimiento.

Lo que debe saber

Aunque tanto la base de datos de Microsoft SQL Server como la base de datos de PostgreSQL son compatibles con ANSI-SQL, aún existen diferencias entre su sintaxis SQL, tipos de datos, distinción entre mayúsculas y minúsculas, y hace que la transferencia de datos no sea tan trivial.

Antes de la migración, comprenda las diferencias entre MSSQL y PostgreSQL. Hay muchas funciones en ambas bases de datos, por lo que debe conocer el comportamiento de esas funciones/funciones en MSSQL y PostgreSQL. Consulte algunas diferencias importantes que debe conocer antes de la migración.

Asignación de tipos de datos

Algunos de los tipos de datos de MSSQL no coinciden directamente con los tipos de datos de PostgreSQL, por lo que debe cambiarlos al tipo de datos de PostgreSQL correspondiente.

Consulte la siguiente tabla.

Incompatibilidades en MS SQL Server y PostgreSQL

Hay muchas incompatibilidades presentes en MS SQL Server y PostgreSQL, puede ver algunas de ellas aquí. Puede automatizarlos creando extensiones para que pueda usar la función MS SQL Server tal como está en PostgreSQL y pueda ahorrar tiempo.

PARTE DE LA FECHA

DATEPART debe ser reemplazado por DATE_PART en PostgreSQL.

Ejemplo

MSSQL:

DATEPART( datepart , date )

PostgreSQL:

date_part( text , timestamp )
date_part( text , interval )

ESNULL

La función ISNULL debe ser reemplazada por la función COALESCE en PostgreSQL.

Ejemplo

Servidor MS SQL:

ISNULL(exp, replacement)

PostgreSQL:

COALESCE(exp, replacement)

ESPACIO

La función ESPACIO en MS SQL Server debe ser reemplazada por la función REPETIR en PostgreSQL.

Ejemplo

Servidor MS SQL:

SPACE($n)

Donde $n es el número de espacios a devolver.

PostgreSQL:

REPEAT(‘ ’, $n)

AÑADIRFECHA

PostgreSQL no proporciona una función DATEADD similar a MS SQL Server, puede usar la aritmética de fecha y hora con literales de intervalo para obtener los mismos resultados.

Ejemplo

Servidor MS SQL:

--Add 2 day to the current date
SELECT DATEADD(day, 2, GETDATE());

PostgreSQL:

--Add 2 day to the current date
SELECT CURRENT_DATE + INTERVAL ‘2 day’;

Concatenación de cadenas

MS SQL Server usa '+' para la concatenación de cadenas, mientras que PostgreSQL usa '||' para lo mismo.

Ejemplo

Servidor MS SQL:

SELECT FirstName + LastName FROM employee;

PostgreSQL:

SELECT FirstName || LastName FROM employee;

CARÍNDICE

Hay una función CHARINDEX en PostgreSQL. Puede reemplazar esta función por la función POSICIÓN equivalente de PostgreSQL.

Ejemplo

Servidor MS SQL:

SELECT CHARINDEX('our', 'resource');

PostgreSQL:

SELECT POSITION('our' in 'resource');

GETDATE

La función GETDATE devuelve la fecha y hora actual. No hay una función GETDATE en PostgreSQL, pero hay una función NOW() para el mismo propósito. Si hay varias ocurrencias de la función GETDATE, puede automatizarlas usando la extensión. Consulte cómo crear módulos usando la extensión.

Ejemplo

Servidor MS SQL:

SELECT GETDATE();

PostgreSQL:

SELECT NOW();

Herramientas

Puede usar algunas herramientas para migrar la base de datos de MS SQL Server a PostgreSQL. Pruebe la herramienta antes de usarla.

1. Gloader

   Puede usar la herramienta pgloader para migrar la base de datos MS SQL a PostgreSQL. Los comandos en pgloader cargan los datos de la base de datos MS SQL. Pgloader admite el descubrimiento automático del esquema, incluida la creación de índices, la clave principal y las restricciones de claves externas.

   Pgloader proporciona varias reglas de conversión que pueden convertir el tipo de datos de MS SQL en un tipo de datos de PostgreSQL.

2. Sqlserver2pgsql

   Esta es otra herramienta de migración de código abierto para convertir la base de datos de Microsoft SQL Server en una base de datos PostgreSQL, de la forma más automática posible. Sqlserver2pgsql está escrito en Perl.

   La herramienta Sqlserver2pgsql hace dos cosas:

   1. Convierte un esquema de SQL Server en un esquema de PostgreSQL
   2. Puede producir un jib Pentaho Data Integrator (Kettle) para migrar todos los datos de SQL Server a PostgreSQL. Esta es una parte opcional.

Pruebas

Probar la aplicación y la base de datos migrada es muy importante porque algunas de las funciones son las mismas en ambas bases de datos, sin embargo, el comportamiento es diferente.

Es necesario comprobar algunos escenarios comunes:

• Compruebe si todos los objetos de la base de datos se han convertido correctamente o no.
• Compruebe si el comportamiento de todas las funciones en DML funciona correctamente o no.
• Cargue datos de muestra en ambas bases de datos y verifique el resultado de todas las consultas DML en ambas bases de datos. El resultado de todos los SQL debería ser el mismo.
• Compruebe el rendimiento del DML y mejórelo si es necesario.