Trasferimento dati

Il trasferimento dati copia tabelle, viste, procedure e funzioni da un database a un altro — anche tra motori diversi. Da MySQL a PostgreSQL, da SQLite a SQL Server, dalla produzione a una copia locale.

Aprilo da Strumenti → Data Transfer, oppure clic destro su un database e Data Transfer.

La procedura guidata

1. Origine e destinazione

Scegli connessione e database su entrambi i lati. NabuSQL mostra tipo di connessione, nome, host, porta e versione del server per entrambi, così puoi confermare di puntare dove credi.

2. Selezione degli oggetti

L'albero raggruppa tutto in Tabelle, Viste e Funzioni / Procedure. Spunta ciò che vuoi spostare.

Evidenzia una singola tabella per configurarla a parte: il suo oggetto di destinazione e la modalità — Auto (struttura e record) o Solo DDL (struttura, senza dati).

3. Opzioni

Opzioni tabelle

Opzione	Effetto
Crea tabelle	Crea le tabelle di destinazione. Disattiva se esistono già
Includi indici	Ricrea gli indici
Includi valori predefiniti	Trasferisce i valori predefiniti delle colonne
Includi chiavi esterne	Ricrea i vincoli FK
Includi engine/tipo tabella	Engine MySQL, es. InnoDB
Includi set di caratteri	Trasferisce il charset
Includi auto increment	Mantiene le colonne auto-increment
Includi trigger	Copia i trigger collegati alle tabelle selezionate — solo stesso engine, vedi sotto
Elimina oggetti di destinazione prima di creare	Elimina prima ciò che c'è
Adegua il DEFINER all'utente di destinazione	Riscrive il DEFINER di viste, routine e trigger copiati con l'account con cui gira il trasferimento. Attivo per impostazione predefinita

Opzioni record

Opzione	Effetto
Crea record	Copia le righe, non solo la struttura
Usa transazione	Racchiude il trasferimento: un errore annulla tutto
Usa istruzioni INSERT estese	INSERT multiriga — decisamente più veloce
Continua in caso di errore	Prosegue oltre le righe difettose invece di fermarsi
Dimensione batch	Righe per batch

Altro

• Crea il database di destinazione se non esiste — lo crea quando manca.

4. Esecuzione

L'avanzamento è mostrato per fase — creazione dello schema, poi copia — e per oggetto. Il risultato è Trasferimento completato, Completato con errori con l'elenco, oppure un errore.

Trigger

Includi trigger porta con sé i trigger appesi alle tabelle che hai selezionato — nel passo 2 non esiste un gruppo separato per i trigger. Due cose vale la pena sapere:

• Vengono creati dopo la copia delle righe, come ultima fase della tabella. Creati prima del ciclo di insert scatterebbero una volta per ogni riga copiata, corrompendo i dati in silenzio invece di fallire.
• Solo fra engine uguali. Il corpo di un trigger non è traducibile fra dialetti, quindi in un trasferimento fra engine diversi i trigger vengono saltati — senza errore e senza interrompere il trasferimento.

DEFINER

MySQL e MariaDB marchiano ogni vista, procedura, funzione e trigger con DEFINER=`utente`@`host`, e quell'account deve esistere sul server su cui l'oggetto atterra. Copia una vista definita da root@localhost su un server a cui ti colleghi come web@% e o si rifiuta di essere creata, o si rompe la prima volta che qualcuno la usa.

Adegua il DEFINER all'utente di destinazione — attivo per impostazione predefinita — riscrive il DEFINER di ogni vista, routine e trigger copiati con l'account con cui il trasferimento è collegato sul lato di destinazione. Quando quell'account non è determinabile, la clausola viene invece rimossa e la riempie il server stesso.

Disattivala per copiare i definer alla lettera: è ciò che serve quando stai replicando un server i cui account coincidono da entrambi i lati.

Profili

Salva profilo memorizza l'intera configurazione — origine, destinazione, selezione degli oggetti e opzioni. Carica profilo la ripristina. Conviene per ogni trasferimento che esegui più di una volta, come aggiornare un database di sviluppo dalla produzione.

Cambiare motore: usa questo, non un dump

Un dump — da Backup e ripristino o da mysqldump — è scritto nel SQL del motore di origine ed è pensato per essere ripristinato sullo stesso tipo di server. Puntarlo su un motore diverso fallisce già alla prima istruzione, e le ragioni non sono superficiali:

• Gli identificatori sono quotati alla maniera del motore. I backtick di MySQL sono un errore di sintassi ovunque altrove, e compaiono su ogni tabella e colonna del file.
• I tipi non coincidono — int(11), datetime, longtext, ENUM(...) inline.
• Interi costrutti non hanno corrispettivo — AUTO_INCREMENT, ENGINE=InnoDB, DEFAULT CHARSET, le definizioni KEY dentro CREATE TABLE, LOCK TABLES.
• L'escape delle stringhe è diverso. MySQL sfugge un apice come \'; PostgreSQL legge la barra rovesciata alla lettera, quindi la stringa finisce troppo presto. È l'unico dei quattro che corrompe i dati invece di fallire rumorosamente, ed è per questo il peggiore.

Il trasferimento dati aggira tutto questo perché non sposta mai testo SQL. Legge lo schema di origine, rigenera il DDL per il dialetto di destinazione e copia le righe attraverso il driver con i valori passati come parametri anziché incollati nelle istruzioni.

La regola pratica:

	Usa
Stesso motore, o con un file in mezzo	Backup e ripristino
Motore diverso	Trasferimento dati

Cambiare motore: usa questo, non un dump

Un dump — da Backup e ripristino o da mysqldump — è scritto nell'SQL del motore di origine ed è pensato per essere ripristinato sullo stesso tipo di server. Puntarlo su un motore diverso fallisce alla prima istruzione, e le ragioni non sono superficiali:

• Gli identificatori sono citati alla maniera del motore. I backtick di MySQL sono un errore di sintassi ovunque altrove, e compaiono su ogni tabella e colonna del file.
• I tipi non coincidono — int(11), datetime, longtext, ENUM(...) inline.
• Interi costrutti non hanno corrispondente — AUTO_INCREMENT, ENGINE=InnoDB, DEFAULT CHARSET, le definizioni KEY dentro CREATE TABLE, LOCK TABLES.
• L'escape delle stringhe è diverso. MySQL scrive un apice come \'; PostgreSQL legge la barra rovesciata alla lettera, quindi la stringa finisce prima. Questo corrompe i dati invece di fallire rumorosamente, ed è il peggiore dei quattro.

Il trasferimento dati aggira tutto questo perché non sposta mai testo SQL. Legge lo schema di origine, rigenera il DDL per il dialetto di destinazione e copia le righe attraverso il driver con i valori passati come parametri anziché incollati nelle istruzioni.

La regola pratica:

	Usa
Stesso motore, o un file intermedio	Backup e ripristino
Motore diverso	Trasferimento dati

Note tra motori diversi

Spostarsi tra motori significa che i tipi vengono mappati, non copiati. Controlla il risultato quando l'origine usa tipi specifici — ENUM di MySQL, array di PostgreSQL, UNIQUEIDENTIFIER di SQL Server.

Procedure e funzioni sono copiate come testo sorgente. I dialetti SQL differiscono, quindi una routine che funziona su MySQL spesso va modificata dopo l'arrivo su PostgreSQL. Tabelle e viste sono la parte che viaggia senza attriti.

Inizia con una prova

Per un primo trasferimento tra server sconosciuti seleziona una tabella, imposta Solo DDL ed esegui. Vedrai come vengono mappati i tipi prima di impegnarti in una copia completa.

Correlati

• Backup e ripristino — stesso server, con un file in mezzo.
• Confronto di struttura e dati — verifica che i due lati coincidano.