Breve introduzione
I concetti di migration e di seeder vengono spesso utilizzati all'interno di framework e strutture più grandi che vanno ad incapsulare il vostro progetto.
Un esempio potrebbe essere quello di Laravel, di Symfony o di CodeIgniter.
Cos'è una migration?
Una migration è sostanzialmente uno script / programma.
Tale programma svolge delle modifiche alla struttura del vostro database. Tutte le modifiche che verranno quindi svolte al vostro database dovranno essere prima scritte su una migration e poi eseguite.
Esempio:
Se avete una tabella "utenti" con i seguenti campi: nickname, email, password e volete aggiungere un campo "email_confermata" di tipo boolean, dovrete scrivere una migration che andrà ad aggiungere il campo nel caso la migration venga eseguita, o a toglierlo in caso di rollback.
Cos'è un seeder?
Cosi come la migration, anche un seeder è uno script / programma, ma nel caso del seeder, esso non va a toccare minimamente la struttura del database, la quale viene gestita esclusivamente dalle migration, bensì va ad alimentare il contenuto delle tabelle.
Ci sono dei casi in cui delle applicazioni necessitano di alcuni dati "base" al loro avvio, ad esempio le impostazioni iniziali di un sito o gli utenti per l'amministrazione. I seeder permettono di riempire il database con questi valori alla messa in produzione di un progetto.
Inoltre, i seeder possono essere utilizzati anche per scopi di test quando si ha a che fare con grandi volumi di dati e si ha il bisogno di riprodurli più volte.
Quando utilizzarli?
Migration e seeder vanno utilizzati principalmente quando si ha a che fare con progetti che vengono mantenuti da più persone (vedi git e versioning).
Per progetti piccoli o test, raramente vengono utilizzate delle migration, ma quando il progetto è abbastanza grande si consiglia l'uso di migration. In questo modo sarà possibile lavorare sulla struttura del DB senza avere problematiche di alcun tipo.
Un classico esempio sbagliato, che ho notato personalmente su più progetti, è il lavorare sulla struttura del DB utilizzando i file d'esportazione .sql per poi passarli agli altri collaboratori.
Grazie alle migration è possibile passare ai collaboratori ( o aggiungere sul repository ) solo le migrazioni contenenti le modifiche effettuate, in questo modo i collaboratori potranno avviare le migration che aggiorneranno la struttura del DB aggiungendo o rimuovendo tabelle, colonne, indici etc.
I concetti di migration e di seeder vengono spesso utilizzati all'interno di framework e strutture più grandi che vanno ad incapsulare il vostro progetto.
Un esempio potrebbe essere quello di Laravel, di Symfony o di CodeIgniter.
Cos'è una migration?
Una migration è sostanzialmente uno script / programma.
Tale programma svolge delle modifiche alla struttura del vostro database. Tutte le modifiche che verranno quindi svolte al vostro database dovranno essere prima scritte su una migration e poi eseguite.
Esempio:
Se avete una tabella "utenti" con i seguenti campi: nickname, email, password e volete aggiungere un campo "email_confermata" di tipo boolean, dovrete scrivere una migration che andrà ad aggiungere il campo nel caso la migration venga eseguita, o a toglierlo in caso di rollback.
Cos'è un seeder?
Cosi come la migration, anche un seeder è uno script / programma, ma nel caso del seeder, esso non va a toccare minimamente la struttura del database, la quale viene gestita esclusivamente dalle migration, bensì va ad alimentare il contenuto delle tabelle.
Ci sono dei casi in cui delle applicazioni necessitano di alcuni dati "base" al loro avvio, ad esempio le impostazioni iniziali di un sito o gli utenti per l'amministrazione. I seeder permettono di riempire il database con questi valori alla messa in produzione di un progetto.
Inoltre, i seeder possono essere utilizzati anche per scopi di test quando si ha a che fare con grandi volumi di dati e si ha il bisogno di riprodurli più volte.
Quando utilizzarli?
Migration e seeder vanno utilizzati principalmente quando si ha a che fare con progetti che vengono mantenuti da più persone (vedi git e versioning).
Per progetti piccoli o test, raramente vengono utilizzate delle migration, ma quando il progetto è abbastanza grande si consiglia l'uso di migration. In questo modo sarà possibile lavorare sulla struttura del DB senza avere problematiche di alcun tipo.
Un classico esempio sbagliato, che ho notato personalmente su più progetti, è il lavorare sulla struttura del DB utilizzando i file d'esportazione .sql per poi passarli agli altri collaboratori.
Grazie alle migration è possibile passare ai collaboratori ( o aggiungere sul repository ) solo le migrazioni contenenti le modifiche effettuate, in questo modo i collaboratori potranno avviare le migration che aggiorneranno la struttura del DB aggiungendo o rimuovendo tabelle, colonne, indici etc.
