Transfert de données

Le transfert de données copie tables, vues, procédures et fonctions d’une base vers une autre — y compris entre moteurs différents. De MySQL vers PostgreSQL, de SQLite vers SQL Server, de la production vers une copie locale.

Ouvrez-le depuis Outils → Transfert de données, ou faites un clic droit sur une base et choisissez Transfert de données.

L’assistant

1. Source et cible

Choisissez une connexion et une base de chaque côté. NabuSQL affiche le type de connexion, le nom, l’hôte, le port et la version du serveur pour les deux, afin que vous puissiez confirmer que vous visez bien ce que vous pensez.

2. Sélection des objets

L’arborescence regroupe tout en Tables, Vues et Fonctions / Procédures. Cochez ce que vous voulez déplacer.

Mettez une table en surbrillance pour la configurer individuellement : le nom de son objet cible et son mode — Auto (structure et enregistrements) ou DDL uniquement (structure, sans données).

3. Options

Options des tables

Option	Effet
Créer les tables	Crée les tables cibles. Désactivez si elles existent déjà
Inclure les index	Recrée les index
Inclure les valeurs par défaut	Reprend les valeurs par défaut des colonnes
Inclure les contraintes de clé étrangère	Recrée les contraintes FK
Inclure le moteur/type de table	Moteur MySQL, par ex. InnoDB
Inclure le jeu de caractères	Reprend le jeu de caractères
Inclure l’auto-incrément	Conserve les colonnes auto-incrémentées
Inclure les déclencheurs	Copie les déclencheurs attachés aux tables sélectionnées — même moteur uniquement, voir ci-dessous
Supprimer les objets cibles avant création	Supprime d’abord ce qui existe
Adapter le DEFINER à l’utilisateur cible	Réécrit le DEFINER des vues, routines et déclencheurs copiés pour le compte sous lequel s’exécute le transfert. Activé par défaut

Options des enregistrements

Option	Effet
Créer les enregistrements	Copie les lignes, pas seulement la structure
Utiliser une transaction	Encapsule le transfert pour qu’un échec soit annulé
Utiliser des INSERT étendus	INSERT multi-lignes — nettement plus rapide
Continuer en cas d’erreur	Poursuit malgré les lignes en échec au lieu de s’arrêter
Taille de lot	Lignes par lot

Autres

• Créer la base cible si elle n’existe pas — crée la base lorsqu’elle est absente.

4. Exécution

La progression est affichée par phase — création du schéma, puis copie — et par objet. Le résultat est Transfert terminé, Terminé avec des erreurs avec la liste, ou une erreur.

Déclencheurs

Inclure les déclencheurs reprend les déclencheurs rattachés aux tables sélectionnées — il n’y a pas de groupe de déclencheurs distinct à l’étape 2. Deux points à connaître :

• Ils sont créés après la copie des lignes, en dernière phase de la table. Créés avant la boucle d’insertion, ils se déclencheraient une fois par ligne copiée, ce qui corromprait discrètement les données au lieu d’échouer.
• Même moteur uniquement. Le corps d’un déclencheur ne peut pas être traduit d’un dialecte à l’autre, donc lors d’un transfert entre moteurs, les déclencheurs sont ignorés — silencieusement, sans faire échouer le transfert.

DEFINER

MySQL et MariaDB marquent chaque vue, procédure, fonction et déclencheur d’un DEFINER=`user`@`host`, et ce compte doit exister sur le serveur où l’objet arrive. Copiez une vue définie par root@localhost sur un serveur où vous vous connectez en tant que web@%, et soit elle refuse d’être créée, soit elle casse à la première utilisation.

Adapter le DEFINER à l’utilisateur cible — activé par défaut — réécrit le DEFINER de chaque vue, routine et déclencheur copié pour le compte sous lequel le transfert est connecté côté cible. Lorsque ce compte ne peut pas être déterminé, la clause est supprimée et le serveur la remplit lui-même.

Désactivez-le pour copier les DEFINER tels quels, ce que vous voulez lorsque vous répliquez un serveur dont les comptes correspondent des deux côtés.

Profils

Enregistrer le profil stocke toute la configuration — source, cible, sélection des objets et options. Charger un profil la restaure. Utile pour tout transfert que vous exécutez plus d’une fois, comme rafraîchir une base de développement depuis la production.

Changer de moteur : utilisez ceci, pas un dump

Un dump — issu de Sauvegarde et restauration, ou de mysqldump — est écrit dans le SQL propre au moteur source et est destiné à être restauré sur le même type de serveur. L’appliquer à un autre moteur échoue dès la première instruction, et les raisons ne sont pas superficielles :

• Les identifiants sont entourés à la manière du moteur. Les accents graves de MySQL sont une erreur de syntaxe partout ailleurs, et ils apparaissent sur chaque table et colonne du fichier.
• Les types ne correspondent pas — int(11), datetime, longtext, ENUM(...) en ligne.
• Des constructions entières n’ont pas d’équivalent — AUTO_INCREMENT, ENGINE=InnoDB, DEFAULT CHARSET, définitions KEY en ligne dans CREATE TABLE, LOCK TABLES.
• L’échappement des chaînes diffère. MySQL échappe une apostrophe en \' ; PostgreSQL lit la barre oblique inverse littéralement, donc la chaîne se termine trop tôt. Celle-ci corrompt les données au lieu d’échouer bruyamment, ce qui en fait la pire des quatre.

Le transfert de données évite tout cela car il ne déplace jamais de texte SQL. Il lit le schéma source, régénère le DDL dans le dialecte de la cible et copie les lignes via le pilote, avec des valeurs liées comme paramètres plutôt que collées dans les instructions.

La règle générale :

	Utiliser
Même moteur, ou un fichier entre les deux	Sauvegarde et restauration
Moteur différent	Transfert de données

Remarques sur les transferts entre moteurs

Passer d’un moteur à l’autre signifie que les types sont convertis, pas copiés. Vérifiez le résultat lorsque la source utilise des types propres à un moteur — ENUM de MySQL, tableaux PostgreSQL, UNIQUEIDENTIFIER de SQL Server.

Les procédures et fonctions sont copiées sous forme de texte source. Les dialectes SQL diffèrent d’un moteur à l’autre, donc une routine qui fonctionne sur MySQL devra souvent être modifiée une fois arrivée sur PostgreSQL. Les tables et les vues sont les éléments qui voyagent proprement.

Commencez par un essai à blanc

Pour un premier transfert entre serveurs que vous ne connaissez pas, sélectionnez une table, choisissez DDL uniquement, et lancez-le. Vous verrez comment les types sont convertis avant de vous engager dans une copie complète.

Entre MySQL et MariaDB

Les deux partagent un dialecte, donc les types de colonnes voyagent normalement exactement tels que déclarés. L’exception est un type que la version cible ne possède pas — typiquement les types récents de MariaDB allant vers MySQL ou vers un MariaDB plus ancien. Ces colonnes sont créées avec le type simple qui contient les mêmes valeurs, et l’aperçu le signale avant toute exécution :

Type source	Sur une cible qui ne l’a pas
UUID	CHAR(36)
INET4	VARCHAR(15)
INET6	VARCHAR(45)
VECTOR(n)	VARBINARY(4·n) — les mêmes octets
XMLTYPE	LONGTEXT
JSON (MySQL avant 5.7.8, MariaDB avant 10.2.7)	LONGTEXT

Ce que possède la cible est déterminé à partir de sa version réelle — les mêmes règles que la liste des types — cela fonctionne donc aussi lorsqu’un serveur MariaDB a été enregistré comme connexion MySQL.

Voir aussi

• Sauvegarde et restauration — même serveur, fichier entre les deux.
• Comparer structure et données — vérifier ensuite que les deux côtés correspondent.