omkring samme tid blev Git populær, tendensen til at skrive internetbaserede applikationer ved hjælp af objekt-relationel kortlægning (ORM) biblioteker blev også kendt. Nøgleideen var dette: da udviklere kan foretage ændringer i kode, der er lette at rulle tilbage ved hjælp af Git, hvorfor kan udviklere ikke gøre det samme, når det kommer til skemaændringer? Når alt kommer til alt involverer enhver rimelig ny funktion kode-og skemaændringer. Så populære rammer som Rails og Django tilføjede ORM og database migration (også kendt som schema migration) som en del af deres tilbud. Men databasemigrering som koncept er ikke begrænset til populære internetrammer. Der er endda standalone database migration programbiblioteker som f.eks. Kan du forestille dig at kunne rulle tilbage granulære ændringer i skemaet, mens du skriver din kode? Alt for ofte finder jeg, at artikler om databasemigrering ikke diskuterer, hvad det betyder at aktivt gøre en som udvikler. Det vil jeg rette op på her. Med det i tankerne vil jeg i dag give dig det store billede af, hvad databasemigrering indebærer, og hvordan man gør det i et aktivt udviklingsmiljø. Jeg deler dette op i tre sektioner, der dækker, hvad der sker under migreringsprocessen, de anvendte almindelige værktøjer og de faldgruber, der kan dukke op under databasemigrering. Dette skal give en nybegynderudvikler værktøjerne til hurtigt at lære de vigtigste ideer bag Datamigrering og også lære potentielle faldgruber, der skal undgås, når du bruger databasemigrering som en del af hans eller hendes udviklingsværktøjskasse.
Hvad Sker Der Under Databasemigrering?
nu hvor du ved, hvordan databasemigrationer opstod, lad mig lede dig gennem, hvad de faktisk indebærer.
granulære ændringer genereres som individuelle scriptede filer
jeg nævnte, hvordan databasemigrationer dybest set sporer granulære ændringer i dit databaseskema (og nogle gange også til dine data). Disse granulære ændringer afspejles typisk som separate scriptede filer. På den måde afspejles dine granulære skemaændringer som kode, der kan optages med ethvert versionsstyringsprogram. Dette er et eksempel på en migrationsfil i Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
ikke kun kan du have migrationer som enkeltstående filer, du kan også have det aktuelle databaseskema som sin egen fil. Typisk er dette kendt som en skemafil.
Databasemigreringsskripter er Værktøjsafhængige
husk databasemigreringsskriptet i Ruby fra vores tidligere eksempel. Her er en anden database migration fil fra den uafhængige kilde kontrol for databasen.
<?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>
denne gang er filen i format. I virkeligheden kan Likebase producere migrationsændringer (eller ændringssæt, som de gerne kalder dem) i flere formater som f.eks. Så medmindre du vil håndskrive din databasemigrering i format, er der ingen reelle standarder på tværs af, hvordan migreringsfilerne oprettes. Selvfølgelig kan du skrive dine egne brugerdefinerede databasemigreringsskripter i filerne. Men hvorfor håndskrive og ved et uheld indføre fejl, når du kan gøre brug af værktøjer til at autogenerere databasen migrationer?
Hvordan udfører du en Databasemigrering?
nu ved du, hvad en databasemigrering er. Du skal også vide (i det mindste konceptuelt), hvordan du udfører en databasemigrering. Desværre er der slet ingen standarder for databasemigreringsfiler, hvilket betyder, at vi ikke kan komme for meget i detaljer om, hvordan vi opretter dem. Med andre ord, hvordan du udfører en databasemigrering afhænger meget af det specifikke værktøj, du bruger til opgaven. I dette afsnit dækker jeg de to mest almindelige måder at udføre en databasemigrering på.
mulighed 1: Brug et Ramme/Sprogafhængigt Bibliotek
hvis du bruger et populært sprog (Ruby, PHP, Python osv.) eller rammer (skinner, Django osv.), så er der veldokumenterede biblioteker til Datamigrering inden for universet af den valgte ramme/sprog. De populære internetrammer vil naturligvis komme sammen med databasemigreringsfunktionerne. Afhængigt af opsætningen kan du endda bytte den oprindelige databasemigrering til andre biblioteker inden for det valgte sprog. Typisk i dette scenario genererer du migrationsfilerne ved hjælp af kommandolinjen. Lejlighedsvis skal du muligvis håndskrive den brugerdefinerede kode for nogle ændringer, f.eks. Bortset fra det tager biblioteket valgt inden for rammerne/sproget stort set sig af dette for dig.
Mulighed 2: Brug uafhængig database-Migrationsfokuseret program
i nogle tilfælde vil du bruge programmer som f.eks. Ved at gøre dette undgår du at blive låst fast i en bestemt ramme eller et bestemt sprog. Dette betyder ikke, at du har nul lock-in. Tag for eksempel flyvevejen, som fungerer godt med forskellige databaser som f.eks. Hvis du ikke bruger Java-baseret migration (som låser dig ind i Java), kan du ende med at bruge Java-baseret migration (som låser dig til dit valg af database og Flyvej). Den gode nyhed er, at de begge er relativt nemme at bruge. De giver også en kommandolinjemåde til at generere migreringerne og tillade brugerdefineret kodning til at fange databaseskemavandringerne.
valg af den bedste mulighed for dig
her er min mening om at vælge mellem begge muligheder. Jeg har tendens til at se de fleste udviklere vælge mulighed 1. Normalt er det fordi udviklere allerede har et foretrukket sprog / ramme, så kognitivt set føles det ikke som om de lærer (endnu) et andet stykke program. Og lock-in (i tilfælde af Mulighed 1 ville dette være til rammen og sproget) er helt frivilligt og ønsket. Du kan gøre sagen til Mulighed 2, hvis dit team ikke fuldt ud har forpligtet sig til et bestemt sprog eller en bestemt ramme. Uanset hvad du går efter, undgå at ændre dit valg unødigt midtvejs gennem udvikling. Databasemigrering er ikke et område, hvor ændring af værktøjerne giver dig enorme fordele. De fleste af fordelene kommer fra blot at have database migration oprettet i første omgang.
farerne ved Databasemigrering og hvordan man undgår dem
i det foregående afsnit dækkede jeg de to hovedtyper af værktøjer til databasemigrering: rammer/sprogafhængige og selvstændige programmer. Begge typer er nemme at bruge. Nu vil jeg anbefale tre bedste fremgangsmåder, når det kommer til faktisk at udføre en databasemigrering. Disse tip adresserer den største fare for databasemigrering: du vil undgå at foretage irreversible ændringer.
Vælg et Databasemigreringsværktøj og hold dig til det
jeg nævnte dette kort tidligere, men det er værd at understrege: jeg vil advare mod at foretage unødvendige ændringer i værktøjssættet, simpelthen fordi det er sejt. Husk, at databasemigreringsskripter er afhængige af det værktøj, du bruger til at generere dem. Der er ingen ordentlige standarder for disse scripts. Hvis du virkelig vil, kan du endda skrive dine egne i KVM-udsagn. Det introducerer sit eget sæt problemer; for eksempel kan dine skripter sandsynligvis være databaseafhængige. Det kan være, at der ikke er nogen grund til at spørge ind til siden, og vice versa. Så enten er du låst i dit databasemigreringsværktøj, eller du er låst i dit valg af database—eller i nogle tilfælde endda begge dele. Der er ingen åbenlyse fordele ved at skifte dit værktøjssæt ofte, så mit forslag er at vælge et databasemigreringsværktøj og holde sig til det. Der er bedre ting at gøre med din tid end spin dine hjul unødigt.
Slet kun rækker eller kolonner, når du er helt sikker på, at du skal
når det kommer til migrationer, kan du for det meste vende dem, når du har brug for det. Typiske databasemigreringsværktøjer kan håndtere enkle reversible ændringer. Og selv når de ikke kan, kan du nemt tilføje din egen brugerdefinerede kode for at hjælpe med at vende. For eksempel, i Skinner, du blot tilføje koden under reversibel.
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
de sværeste ændringer at vende har tendens til at involvere sletning af ting: specifikt sletning af kolonner eller rækker af data. Hvis din database indeholder en masse data, kan du ende med at skulle skrive en betydelig mængde brugerdefineret kode for at prøve at vende dine ændringer. Så hvis du overvejer at slette data fra din database, skal du være ekstra forsigtig. Disse typer af ændringer er svære at fortryde. Andre ændringer, der er svære at vende, inkluderer omdøbning af kolonner og ændring af datatypen for en kolonne, der allerede indeholder data. En tommelfingerregel, jeg kan lide at gå med, er dette: du bør næsten aldrig slette kolonner til næste major (du kender semver, ikke?) udgivelse. Denne regel gælder, selvom jeg har kolonner, jeg vil stoppe med at bruge. I stedet for at slette kolonner, vil jeg annoncere i de mindre versioner, hvilke kolonner der vil blive forældet fremadrettet. Når det er tid til en større udgivelse, vil jeg så slippe disse kolonner helt. På den måde reducerer jeg chancerne for at udføre en utilsigtet, uønsket ændring, der vil være en forfærdelig proces at vende i hånden.
Implement Feature Flags
en anden fremragende strategi for databasemigrering er implementering af funktionsflag, især når du har et stort team, og flere mennesker forsøger at implementere forskellige funktioner til den samme kodebase. “En kraftfuld teknik, der giver hold mulighed for at ændre systemadfærd uden at ændre kode.”Faktisk, jo større dit team og jo mere kompleks din kodebase er, jo flere funktionsflag skinner. Funktionsflag hjælper med at mindske risikoen, når det kommer til databasemigrationer. Forsøger at udrede ændringerne, når du har brug for at rulle tilbage visse funktioner kan være en reel mareridt. Funktionsflag fungerer lige så godt, uanset om du vil foretage små eller store databaseskemaændringer. Når du bruger funktionsflag, jeg anbefaler, at du sigter mod hyppigere og granulære ændringer generelt. Og du kan virkelig se, hvordan funktionsflag hjælper din udviklingsproces, når du udfører en massiv skemaændring. Venligst stadig sigte mod at bryde denne massive skemaændring i mindre, tynde skiver. Du behøver ikke at imponere nogen med, hvor meget du kan presse i en ændring. Bedre at tilføje sikkerhedsforanstaltninger til din udviklingspraksis ved at implementere alle tre anbefalinger, jeg har talt om i dette afsnit.
konklusion
udviklere har brug for alle de værktøjer, de kan få for at gøre deres liv lettere. Database migration er et af disse must-have værktøjer til udviklerens værktøjskasse. Fremadrettet forudser jeg, at ansættelse af databasemigrationer vil udvikle sig fra en bedste praksis for udvikling til en standard praksis for udvikling. Folk vil se på dig sjovt for slet ikke at bruge databasemigrering. Alligevel er det vigtigt at huske på, hvordan databasemigrationer kan slå tilbage på dig, især for svære at vende skemaændringer. Vær helt sikker på disse ændringer, før du får dem til at gå live. Hvis du ikke allerede bruger databasemigrering i din proces, hvad venter du på? Det er nemt at starte, og du kan endda tilføje det midtvejs gennem din udviklingscyklus. Du vil være taknemmelig for, at du gjorde det. Fordi når dagen kommer, at du skal rulle dine ændringer tilbage, og ændringerne involverer databasen, vil du ønske, at du havde noget til at hjælpe dig med at gøre det på få sekunder. Database migration er, at noget, du vil ønske, du havde.