cam în același timp Git a devenit popular, tendința de scriere a aplicațiilor bazate pe web folosind biblioteci de mapare relațională a obiectelor (ORM) a devenit, de asemenea, bine cunoscută. Ideea cheie a fost aceasta: deoarece dezvoltatorii pot face modificări ale codului ușor de reluat folosind Git, de ce dezvoltatorii nu pot face același lucru atunci când vine vorba de modificările schemei? La urma urmei, orice caracteristică nouă rezonabilă implică modificări de cod și schemă. Cadre atât de populare precum Rails și Django au adăugat ORM și migrarea bazelor de date (cunoscută și sub numele de migrare schemă) ca parte a ofertelor lor. Dar migrarea bazei de date ca concept nu se limitează la cadrele web populare. Există chiar și biblioteci software de migrare a bazelor de date independente, cum ar fi Flyway și Liquibase. Vă puteți imagina posibilitatea de a reveni la modificările granulare ale schemei în timp ce scrieți codul? Prea des, găsesc că articolele despre migrarea bazelor de date nu discută ce înseamnă să faci activ unul, ca dezvoltator. Vreau să corectez asta aici. Având în vedere acest lucru, astăzi vă voi oferi o imagine de ansamblu a ceea ce implică migrarea bazelor de date și cum să o faceți într-un mediu de dezvoltare activ. Voi împărți acest lucru în trei secțiuni, care acoperă ceea ce se întâmplă în timpul procesului de migrare, instrumentele comune utilizate și capcanele care pot apărea în timpul migrării bazei de date. Acest lucru ar trebui să ofere unui dezvoltator începător instrumentele necesare pentru a învăța rapid ideile cheie din spatele migrației datelor și, de asemenea, să învețe potențialele capcane de evitat atunci când utilizează migrarea bazei de date ca parte a setului său de instrumente de dezvoltare.
Ce Se Întâmplă În Timpul Migrării Bazei De Date?
acum, că știți cum au apărut migrațiile bazelor de date, permiteți-mi să vă prezint ceea ce implică de fapt.
modificările granulare sunt generate ca fișiere scriptate individuale
am menționat modul în care migrațiile bazei de date urmăresc practic modificările granulare la schema bazei de date (și uneori și la datele dvs.). Aceste modificări granulare sunt de obicei reflectate ca fișiere scriptate separate. În acest fel, modificările schemei granulare sunt reflectate ca cod care poate fi capturat cu orice software de control al versiunii. Acesta este un exemplu de fișier de migrare în Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
nu numai că puteți avea migrații ca fișiere independente, puteți avea, de asemenea, schema bazei de date curente ca fișier propriu. De obicei, acest lucru este cunoscut sub numele de fișier schemă.
scripturile de migrare a bazei de date sunt dependente de instrumente
reamintiți scriptul de migrare a bazei de date din Ruby din exemplul nostru anterior. Iată un alt fișier de migrare a bazei de date din controlul sursă independent pentru software-ul bazei de date Liquibase.
<?xml version="1.0" encoding="UTF-8"?><databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd"> <changeSet author="bob"> <createTable tableName="department"> <column name="id" type="int"> <constraints primaryKey="true" nullable="false"/> </column> <column name="name" type="varchar(50)"> <constraints nullable="false"/> </column> <column name="active" type="boolean" defaultValueBoolean="true"/> </createTable> </changeSet></databaseChangeLog>
de data aceasta, fișierul este în format XML. De fapt, Liquibase poate produce modificări de migrare (sau seturi de modificări, așa cum le place să le numească) în mai multe formate, cum ar fi XML și JSON. Deci, dacă nu doriți să scrieți de mână migrarea bazei de date în format SQL, nu există standarde reale în modul în care sunt create fișierele de migrare. Desigur, puteți scrie propriile scripturi personalizate de migrare a bazei de date în fișierele SQL. Dar de ce scrie de mână și să introducă accidental bug-uri atunci când se poate face uz de instrumente pentru a autogenera migrațiile bazei de date?
cum efectuați o migrare a bazei de date?
acum știți ce este o migrare a bazei de date. De asemenea, trebuie să știți (cel puțin conceptual) cum să efectuați o migrare a bazei de date. Din păcate, nu există deloc standarde pentru fișierele de migrare a bazelor de date, ceea ce înseamnă că nu putem intra în prea multe detalii despre cum să le creăm. Cu alte cuvinte, modul în care efectuați o migrare a bazei de date depinde în mare măsură de instrumentul specific pe care îl utilizați pentru activitate. În această secțiune, voi acoperi cele două moduri cele mai comune de a efectua o migrare a bazei de date.
opțiunea 1: utilizați un cadru/bibliotecă dependentă de limbă
dacă utilizați un limbaj popular (Ruby, PHP, Python etc.) sau cadru (șine, Django etc.), atunci există biblioteci bine documentate pentru migrarea datelor în universul cadrului/limbii alese. Cadrele web populare vor veni în mod natural la pachet cu caracteristicile de migrare a bazei de date. În funcție de configurare, puteți chiar să schimbați migrarea bazei de date native pentru alte biblioteci din limba aleasă. De obicei, în acest scenariu, generați fișierele de migrare utilizând linia de comandă. Ocazional, poate fi necesar să scrieți manual codul personalizat pentru unele modificări, cum ar fi migrarea datelor sau chiar modul de inversare a modificării în sine. În afară de asta, biblioteca aleasă în cadrul/limba se ocupă destul de mult de acest lucru pentru dvs.
Opțiunea 2: Utilizați Software independent bazat pe migrarea bazei de date
în unele cazuri, veți dori să utilizați software precum Flyway sau Liquibase care acționează doar ca un control sursă pentru baza de date. Procedând astfel, evitați să fiți blocat într-un anumit cadru sau limbă. Acest lucru nu înseamnă că aveți zero lock-in. Luați, de exemplu, Flyway, care funcționează bine cu diverse baze de date, cum ar fi Oracle, MySQL și MariaDB. Dacă nu utilizați migrarea bazată pe Java Flyway (care vă blochează în Java și Flyway), puteți ajunge să utilizați migrarea bazată pe SQL (care vă blochează la alegerea bazei de date și Flyway). Vestea bună este Flyway și Liquibase sunt atât relativ ușor de utilizat. Ei, de asemenea, oferă o modalitate de linie de comandă pentru a genera migrațiile și permite codificare personalizat pentru a captura migrațiile schema bazei de date.
alegerea celei mai bune opțiuni pentru dvs.
iată părerea mea despre alegerea între ambele opțiuni. Am tendința de a vedea majoritatea dezvoltatorilor aleg opțiunea 1. De obicei, asta pentru că dezvoltatorii au deja un limbaj/cadru preferat, deci cognitiv vorbind, nu simt că învață (încă) o altă piesă de software. Iar blocarea (în cazul opțiunii 1, Aceasta ar fi pentru cadru și limbă) este în întregime voluntară și dorită. Puteți susține opțiunea 2 dacă echipa dvs. nu s-a angajat pe deplin într-o anumită limbă sau cadru. Indiferent de ceea ce alegeți, evitați să vă schimbați alegerea inutil la jumătatea dezvoltării. Migrarea bazei de date nu este un domeniu în care schimbarea instrumentelor vă oferă beneficii extraordinare. Cele mai multe dintre beneficiile provin de la pur și simplu având migrarea bazei de date înființat în primul rând.
pericolele migrării bazelor de date și cum să le evităm
în secțiunea anterioară, am acoperit cele două tipuri majore de instrumente pentru migrarea bazelor de date: cadru/software dependent de limbă și software independent. Ambele tipuri sunt ușor de utilizat. Acum, voi recomanda trei cele mai bune practici atunci când vine vorba de efectuarea efectivă a unei migrări a bazei de date. Aceste sfaturi abordează principalul pericol al migrării bazei de date: doriți să evitați efectuarea de modificări ireversibile.
alegeți unul instrument de migrare a bazei de date și respectați-l
am menționat acest lucru pe scurt mai devreme, dar merită subliniat: vreau să avertizez împotriva modificării inutile a setului de instrumente pur și simplu pentru că este cool. Reamintim că scripturile de migrare a bazei de date depind de instrumentul pe care îl utilizați pentru a le genera. Nu există standarde adecvate pentru aceste scripturi. Dacă doriți cu adevărat, puteți chiar să vă scrieți propriile instrucțiuni SQL. Care introduce propriul set de probleme; de exemplu, scripturile SQL sunt susceptibile de a fi dependente de baze de date. Este posibil ca interogările MySQL să nu funcționeze în PostgreSQL și invers. Deci, fie sunteți blocat în instrumentul de migrare a bazei de date, fie sunteți blocat în alegerea bazei de date—sau, în unele cazuri, chiar și în ambele. Nu există beneficii evidente pentru comutarea frecventă a setului de instrumente, așa că sugestia mea este să alegeți un instrument de migrare a bazei de date și să rămâneți la el. Există lucruri mai bune de făcut cu timpul tău decât să-ți învârți roțile inutil.
ștergeți rânduri sau coloane numai atunci când sunteți absolut sigur că trebuie să
când vine vorba de migrații, în cea mai mare parte, le puteți inversa atunci când aveți nevoie. Instrumentele tipice de migrare a bazelor de date pot gestiona modificări simple reversibile. Și chiar și atunci când nu pot, Puteți adăuga cu ușurință propriul cod personalizat pentru a ajuta la inversare. De exemplu, în Rails, pur și simplu adăugați codul sub reversibil.
class ChangeProductsPrice < ActiveRecord::Migration def change reversible do |dir| change_table :products do |t| dir.up { t.change :price, :string } dir.down { t.change :price, :integer } end end endend
cele mai grele modificări de inversat tind să implice ștergerea lucrurilor: în mod specific, ștergerea coloanelor sau a rândurilor de date. Dacă baza dvs. de date conține o mulțime de date, este posibil să fiți nevoit să scrieți o cantitate semnificativă de cod personalizat pentru a încerca să inversați modificările. Deci, dacă aveți în vedere ștergerea datelor din Baza de date, fiți foarte atenți. Aceste tipuri de modificări sunt greu de anulat. Alte modificări greu de inversat includ redenumirea coloanelor și schimbarea tipului de date al unei coloane care conține deja date. O regulă de degetul mare îmi place să merg cu este aceasta: ar trebui să ștergeți aproape niciodată coloane până la următoarea majore (știi semver, dreapta?) eliberare. Această regulă se aplică chiar dacă am coloane pe care vreau să nu le mai folosesc. În loc să ștergeți coloanele, voi anunța în versiunile minore care coloane vor fi depreciate înainte. Când va veni timpul pentru o lansare majoră, voi renunța complet la aceste coloane. În acest fel, reduc șansele de a efectua o schimbare accidentală, nedorită, care va fi un proces îngrozitor de inversat manual.
implementați Semnalizatoarele de obiecte spațiale
o altă strategie excelentă pentru migrarea bazelor de date este implementarea semnalizatoarelor de obiecte spațiale, mai ales atunci când aveți o echipă numeroasă și mai multe persoane încearcă să implementeze diferite obiecte spațiale pentru aceeași bază de cod. Potrivit lui Martin Fowler, steagurile caracteristice sunt ” o tehnică puternică, permițând echipelor să modifice comportamentul sistemului fără a schimba codul.”De fapt, cu cât Echipa dvs. este mai mare și cu cât este mai complexă baza de cod, cu atât mai multe steaguri de caracteristici strălucesc. Semnalizatoarele de funcții ajută la atenuarea riscului atunci când vine vorba de migrarea bazelor de date. Încercarea de a dezlega modificările atunci când trebuie să reveniți la anumite caracteristici poate fi un adevărat coșmar. Steagurile de caracteristici funcționează la fel de bine dacă doriți să efectuați modificări mici sau mari ale schemei bazei de date. Când utilizați steaguri de caracteristici, vă recomand să vizați modificări mai frecvente și granulare în general. Și puteți vedea cu adevărat cum steagurile de caracteristici vă ajută procesul de dezvoltare atunci când efectuați o schimbare masivă a schemei. Vă rugăm să încercați în continuare să rupeți această schimbare masivă a schemei în felii mai mici și subțiri. Nu trebuie să impresionezi pe nimeni cu cât de mult poți stoarce într-o singură schimbare. Mai bine să adăugați garanții practicilor dvs. de dezvoltare prin implementarea tuturor celor trei recomandări despre care am vorbit în această secțiune.
concluzie
dezvoltatorii au nevoie de toate instrumentele pe care le pot obține pentru a-și ușura viața. Migrarea bazei de date este unul dintre acele instrumente obligatorii pentru setul de instrumente al dezvoltatorului. În viitor, prevăd că utilizarea migrațiilor de baze de date va evolua de la o bună practică de dezvoltare la o practică standard de dezvoltare. Oamenii se vor uita la tine amuzant pentru a nu utiliza migrarea bazei de date la toate. Totuși, este important să țineți cont de modul în care migrațiile bazei de date se pot întoarce asupra dvs., în special pentru modificările schemei greu de inversat. Fii absolut sigur de aceste schimbări înainte de a le face să meargă în direct. Dacă nu utilizați deja migrarea bazei de date în procesul dvs., ce așteptați? Este ușor să începeți și puteți chiar să îl adăugați la jumătatea ciclului de dezvoltare. Vei fi recunoscător că ai făcut-o. Pentru că atunci când vine ziua în care trebuie să vă întoarceți modificările și modificările implică baza de date, vă veți dori să aveți ceva care să vă ajute să faceți acest lucru în doar câteva secunde. Migrarea bazei de date este ceva ce vă veți dori să aveți.