Comme vous le savez peut-être, Microsoft SQL Server est un SGBDR très populaire avec des licences très restrictives et un coût de possession élevé si la base de données est de taille importante ou est utilisée par un nombre important de clients. Il fournit une interface très conviviale et facile à apprendre. Cela a abouti à une large base d'utilisateurs installés.
PostgreSQL est la base de données open source la plus avancée au monde. La communauté PostgreSQL est très forte et améliore continuellement les fonctionnalités existantes et implémente de nouvelles fonctionnalités. Selon le classement de popularité de db-engine, PostgreSQL a été le SGBD de l'année 2017.
Pourquoi migrer de MS SQL Server vers PostgreSQL ?
- MS SQL Server est une base de données propriétaire de Microsoft, tandis que PostgreSQL est développé et géré par une communauté mondiale de développeurs Open Source. Si le coût est un problème, alors vous devriez certainement opter pour PostgreSQL. Vous pouvez vérifier les prix ici.
- PostgreSQL est un moteur de base de données multiplateforme et il est disponible pour Windows, Mac, Solaris, FreeBSD et Linux tandis que SQL Server ne fonctionne que sur le système d'exploitation Windows. Comme vous le savez peut-être, PostgreSQL est open source et entièrement gratuit, tandis que le coût de MSSQL Server dépend du nombre d'utilisateurs et de la taille de la base de données.
- Licences open source flexibles et disponibilité facile auprès des fournisseurs de cloud public comme AWS, Google cloud, etc.
- Bénéficiez de modules complémentaires open source pour améliorer les performances.
Ce que vous devez savoir
Bien que la base de données Microsoft SQL Server et la base de données PostgreSQL soient toutes deux conformes à ANSI-SQL, il existe toujours des différences entre leur syntaxe SQL, les types de données, la sensibilité à la casse, et cela rend le transfert de données pas si trivial.
Avant la migration, comprenez les différences entre MSSQL et PostgreSQL. Il existe de nombreuses fonctionnalités dans les deux bases de données, vous devez donc connaître le comportement de ces fonctionnalités/fonctions dans MSSQL et PostgreSQL. Veuillez vérifier certaines différences importantes que vous devez connaître avant la migration.
Mappage des types de données
Certains des types de données de MSSQL ne correspondent pas directement aux types de données PostgreSQL, vous devez donc le remplacer par le type de données PostgreSQL correspondant.
Veuillez vérifier le tableau ci-dessous.
| Microsoft SQL Server | PostgreSQL | |
|---|---|---|
| BIGINT | Entier 64 bits | BIGINT |
| BINAIRE(n) | Chaîne d'octets de longueur fixe | BYTEA |
| BIT | 1, 0 ou NULL | BOOLÉEN |
| CHAR(n) | Chaîne de caractères de longueur fixe, 1 <=n <=8000 | CHAR(n) |
| VARCHAR(n) | Chaîne de caractères de longueur variable, 1 <=n <=8000 | VARCHAR(n) |
| VARCHAR(max) | Chaîne de caractères de longueur variable, <=2 Go | TEXTE |
| VARBINAIRE(n) | Chaîne d'octets de longueur variable, 1 <=n <=8000 | BYTEA |
| VARBINAIRE(max) | Chaîne d'octets de longueur variable, <=2 Go | BYTEA |
| NVARCHAR(n) | Chaîne Unicode UCS-2 de longueur variable | VARCHAR(n) |
| NVARCHAR(max) | Données Unicode UCS-2 de longueur variable, <=2 Go | TEXTE |
| TEXTE | Données de caractères de longueur variable, <=2 Go | TEXTE |
| NTEXT | Données Unicode UCS-2 de longueur variable, <=2 Go | TEXTE |
| DOUBLE PRÉCISION | Nombre à virgule flottante double précision | DOUBLE PRÉCISION |
| FLOAT(p) | Nombre à virgule flottante | DOUBLE PRÉCISION |
| ENTIER | Entier 32 bits | ENTIER |
| NUMÉRIQUE(p,s) | Numéro à virgule fixe | NUMÉRIQUE(p,s) |
| DATE | La date inclut l'année, le mois et le jour | DATE |
| DATEHEURE | Date et heure avec fraction | TIMESTAMP(3) |
| DATETIME2(p) | Date et heure avec fraction | TIMESTAMP(n) |
| DATETIMEOFFSET(p) | Date et heure avec fraction et fuseau horaire | TIMESTAMP(p) AVEC FUSEAU HORAIRE |
| SMALLDATETIME | Date et heure | TIMESTAMP(0) |
| TINYINT | Entier non signé 8 bits, 0 à 255 | SMALLINT |
| IDENTIFIANT UNIQUE | Données GUID (UUID) de 16 octets | CAR(16) |
| ROWVERSION | Données binaires mises à jour automatiquement | BYTEA |
| PEU D'ARGENT | Montant en devise 32 bits | ARGENT |
| IMAGE | Données binaires de longueur variable, <=2 Go | BYTEA |
Incompatibilités dans MS SQL Server et PostgreSQL
Il existe de nombreuses incompatibilités présentes dans MS SQL Server et PostgreSQL, vous pouvez en voir quelques-unes ici. Vous pouvez les automatiser en créant des extensions afin de pouvoir utiliser la fonction MS SQL Server telle qu'elle est dans PostgreSQL et vous faire gagner du temps.
DATEPART
DATEPART doit être remplacé par DATE_PART dans PostgreSQL.
Exemple
MS SQL :
DATEPART( datepart , date )PostgreSQL :
date_part( text , timestamp )
date_part( text , interval )EST NULL
La fonction ISNULL doit être remplacée par la fonction COALESCE dans PostgreSQL.
Exemple
Serveur MS SQL :
ISNULL(exp, replacement)PostgreSQL :
COALESCE(exp, replacement)ESPACE
La fonction SPACE dans MS SQL Server doit être remplacée par la fonction REPEAT dans PostgreSQL.
Exemple
Serveur MS SQL :
SPACE($n)Où $n est le nombre d'espaces à renvoyer.
PostgreSQL :
REPEAT(‘ ’, $n)DATEADJ
PostgreSQL ne fournit pas de fonction DATEADD similaire à MS SQL Server, vous pouvez utiliser l'arithmétique datetime avec des littéraux d'intervalle pour obtenir les mêmes résultats.
Exemple
Serveur 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’;Concaténation de chaînes
MS SQL Server utilise '+' pour la concaténation de chaînes alors que PostgreSQL utilise '||' pour la même chose.
Exemple
Serveur MS SQL :
SELECT FirstName + LastName FROM employee;PostgreSQL :
SELECT FirstName || LastName FROM employee;CHARINDEX
Il existe une fonction CHARINDEX dans PostgreSQL. Vous pouvez remplacer cette fonction par la fonction POSITION équivalente de PostgreSQL.
Exemple
Serveur MS SQL :
SELECT CHARINDEX('our', 'resource');PostgreSQL :
SELECT POSITION('our' in 'resource');OBTENIR DATE
La fonction GETDATE renvoie la date et l'heure actuelles. Il n'y a pas de fonction GETDATE dans PostgreSQL, mais il existe la fonction NOW() dans le même but. S'il existe plusieurs occurrences de la fonction GETDATE, vous pouvez les automatiser à l'aide de l'extension. Veuillez vérifier comment créer des modules à l'aide de l'extension.
Exemple
Serveur MS SQL :
SELECT GETDATE();PostgreSQL :
SELECT NOW();Outils
Vous pouvez utiliser certains outils pour migrer la base de données MS SQL Server vers PostgreSQL. Veuillez tester l'outil avant de l'utiliser.
-
Pgloader
Vous pouvez utiliser l'outil pgloader pour migrer la base de données MS SQL vers PostgreSQL. Les commandes du pgloader chargent les données de la base de données MS SQL. Pgloader prend en charge la découverte automatique du schéma, y compris la construction des index, les contraintes de clé primaire et de clé étrangère.
Pgloader fournit diverses règles de conversion qui peuvent convertir le type de données MS SQL en un type de données PostgreSQL.
-
Sqlserver2pgsql
Il s'agit d'un autre outil de migration open source pour convertir la base de données Microsoft SQL Server en une base de données PostgreSQL, aussi automatiquement que possible. Sqlserver2pgsql est écrit en Perl.
L'outil Sqlserver2pgsql fait deux choses :
- Il convertit un schéma SQL Server en schéma PostgreSQL
- Il peut produire un jib Pentaho Data Integrator (Kettle) pour migrer toutes les données de SQL Server vers PostgreSQL. Ceci est une partie facultative.
Test
Le test de l'application et de la base de données migrée est très important car certaines des fonctions sont les mêmes dans les deux bases de données, cependant, le comportement est différent.
Certains scénarios courants doivent être vérifiés :
- Vérifiez si tous les objets de la base de données sont correctement convertis ou non.
- Vérifiez que le comportement de toutes les fonctions dans DML fonctionne correctement ou non.
- Chargez des exemples de données dans les deux bases de données et vérifiez le résultat de toutes les requêtes DML dans les deux bases de données. Le résultat de tous les SQL doit être le même.
- Vérifiez les performances du DML et améliorez-les si nécessaire.
