Rundt samme tid Git ble populær, trenden for å skrive web – baserte applikasjoner ved hjelp av object-relational mapping (ORM) biblioteker ble også godt kjent. Hovedideen var dette: siden utviklere kan gjøre endringer i kode som er enkle å rulle tilbake ved Hjelp Av Git, hvorfor kan ikke utviklere gjøre det samme når det gjelder skjemaendringer? Tross alt innebærer en rimelig ny funksjon kode-og skjemaendringer. Så populære rammer som Rails og Django lagt ORM og database migrasjon (også kjent som skjema migrasjon) som en del av sine tilbud. Men databasemigrasjon som et konsept er ikke begrenset til populære webrammer. Det er enda frittstående database migrasjon programvare biblioteker Som Flyway og Liquibase. Kan du forestille deg å kunne rulle tilbake granulære endringer i skjemaet mens du skriver koden din? Altfor ofte finner jeg at artikler om databasemigrasjon ikke diskuterer hva det betyr å aktivt gjøre en, som utvikler. Jeg vil rette opp det her. Med det i tankene, i dag skal jeg gi deg det store bildet av hva databaseoverføring innebærer og hvordan du gjør det i et aktivt utviklingsmiljø. Jeg vil bryte dette opp i tre seksjoner, som dekker hva som skjer under migreringsprosessen, de vanlige verktøyene som brukes, og fallgruvene som kan dukke opp under databaseoverføring. Dette bør gi en nybegynner utvikler verktøy for å raskt lære de viktigste ideene bak data migrasjon og også lære potensielle fallgruver å unngå når du bruker database migrasjon som en del av hans eller hennes utvikling verktøykasse.
Hva Skjer Under Databaseoverføring?
nå som du vet hvordan databaseoverføringer kom, la meg gå deg gjennom hva de egentlig innebærer.
Granulære Endringer Genereres Som Individuelle Skriptfiler
jeg nevnte hvordan databaseoverføringer i utgangspunktet sporer granulære endringer i databaseskjemaet ditt (og noen ganger også til dataene dine). Disse granulære endringene gjenspeiles vanligvis som separate skriptfiler. På den måten gjenspeiles de detaljerte skjemaendringene som kode som kan fanges opp med hvilken som helst programvare for versjonskontroll. Dette er et eksempel på en migreringsfil I Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
ikke bare kan du ha migreringer som frittstående filer, du kan også ha gjeldende databaseskjema som egen fil. Vanligvis er dette kjent som en skjemafil.
Databaseoverføringsskript Er Verktøyavhengige
Hent databaseoverføringsskriptet I Ruby fra vårt tidligere eksempel. Her er en annen database migrasjon fil fra den uavhengige kildekontroll for databaseprogramvaren 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>
denne gangen er filen I XML-format. Faktisk Kan Liquibase produsere migrasjonsendringer (eller endringssett, som de liker å kalle dem) i flere formater som XML og JSON. Så med mindre du vil håndskrive databaseoverføringen I SQL-format, er det ingen reelle standarder for hvordan migreringsfilene opprettes. Selvfølgelig kan du skrive dine egne databaseoverføringsskript i SQL-filene. Men hvorfor håndskrive og ved et uhell introdusere feil når du kan bruke verktøy for å autogenerere databasemigrasjonene?
Hvordan Utfører Du En Databaseoverføring?
nå vet du hva en databaseoverføring er. Du må også vite (minst konseptuelt) hvordan du utfører en databaseoverføring. Dessverre er det ingen standarder i det hele tatt for databaseoverføringsfiler, noe som betyr at vi ikke kan komme inn i for mye detalj om hvordan du lager dem. Med andre ord, hvordan du utfører en databaseoverføring, avhenger mye av det bestemte verktøyet du bruker for oppgaven. I denne delen skal jeg dekke de to vanligste måtene å utføre en databaseoverføring på.
Alternativ 1: Bruk Et Rammeverk/Språkavhengig Bibliotek
hvis du bruker et populært språk (Ruby, PHP,Python, etc.) eller rammeverk (Skinner, Django, etc.), så er det veldokumenterte biblioteker for datamigrering innenfor universet av rammen / språket som er valgt. De populære web rammer vil naturligvis komme sammen med databasen migrasjon funksjoner. Avhengig av oppsettet kan du til og med bytte ut den opprinnelige databaseoverføringen for andre biblioteker i det valgte språket. Vanligvis i dette scenariet genererer du overføringsfilene ved hjelp av kommandolinjen. Noen ganger må du kanskje håndskrive den egendefinerte koden for noen endringer, for eksempel dataoverføring eller til og med hvordan du reverserer selve endringen. Annet enn det, tar biblioteket valgt innenfor rammen / språket ganske mye vare på dette for deg.
Alternativ 2: Bruk Uavhengig Database-Migrasjonsfokusert Programvare
i noen tilfeller vil du bruke programvare Som Flyway eller Liquibase som bare fungerer som en kildekontroll for databasen din. Ved å gjøre dette unngår du å bli låst inn i et bestemt rammeverk eller språk. Dette betyr ikke at du har null lock-in. Ta For Eksempel Flyway, som fungerer bra med ulike databaser som Oracle, MySQL og MariaDB. Hvis Du ikke bruker Flyways Java-baserte migrasjon (som låser Deg Inn I Java og Flyway), kan du ende opp med SQL-basert migrasjon (som låser deg til ditt valg av database og Flyway). Den gode nyheten Er At Flyway og Liquibase begge er relativt enkle å bruke. De, også, gi en kommandolinje måte å generere migreringer og tillate tilpasset koding for å fange databaseskjema migreringer.
Velge Det Beste Alternativet For Deg
Her er min mening om å velge mellom begge alternativene. Jeg pleier å se at de fleste utviklere velger alternativ 1. Vanligvis er det fordi utviklere allerede har et foretrukket språk / rammeverk, så kognitivt sett, det føles ikke som om de lærer (ennå) et annet stykke programvare. Og lock-in (i tilfelle av alternativ 1, dette ville være til rammen og språk) er helt frivillig og ønsket. Du kan gjøre saken for alternativ 2 hvis teamet ditt ikke har fullt ut forpliktet seg til et bestemt språk eller rammeverk. Uansett hva du går for, unngå å endre ditt valg unødvendig midtveis gjennom utvikling. Databasemigrasjon er ikke et område der endring av verktøyene gir deg enorme fordeler. De fleste av fordelene kommer fra bare å ha database migrasjon satt opp i første omgang.
Farene Ved Database Migrasjon Og Hvordan Du Kan Unngå Dem
i forrige avsnitt, jeg dekket de to hovedtyper av verktøy for database migrasjon: rammeverk / språk-avhengige og frittstående programvare. Begge typer er enkle å bruke. Nå vil jeg anbefale tre beste praksis når det gjelder å faktisk utføre en databaseoverføring. Disse tipsene adresserer hovedfaren for databaseoverføring: du vil unngå å gjøre irreversible endringer.
Velg Ett Databaseoverføringsverktøy og Hold Deg til det
jeg nevnte dette kort tidligere, men det er verdt å understreke: jeg vil advare mot å gjøre unødvendige endringer i verktøysettet bare fordi det er kult. Husk at databaseoverføringsskript er avhengig av verktøyet du bruker til å generere dem. Det er ingen riktige standarder for disse skriptene. Hvis du virkelig vil, kan du til og med skrive din EGEN I SQL-setninger. Det introduserer sitt eget sett med problemer; FOR eksempel KAN SQL-skriptene dine sannsynligvis være databaseavhengige. MySQL-spørringer fungerer kanskje ikke I PostgreSQL, og omvendt. Så enten er du låst inn i databaseoverføringsverktøyet ditt, eller du er låst inn i ditt valg av database—eller i noen tilfeller, til og med begge deler. Det er ingen åpenbare fordeler med å bytte verktøysett ofte, så mitt forslag er å velge et databaseoverføringsverktøy og holde fast ved det. Det er bedre ting å gjøre med tiden din enn å spinne hjulene unødvendig.
Slett Rader Eller Kolonner Bare Når Du Er Helt Sikker På At Du Må
Når det gjelder migreringer, kan du for det meste reversere Dem når du trenger det. Typiske databasemigreringsverktøy kan håndtere enkle reversible endringer. Og selv når de ikke kan, kan du enkelt legge til din egen tilpassede kode for å hjelpe deg med å reversere. For Eksempel, i Rails, legger du bare til 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 vanskeligste endringene å reversere har en tendens til å innebære å slette ting: spesielt slette kolonner eller rader med data. Hvis databasen inneholder mye data, kan du ende opp med å skrive en betydelig mengde egendefinert kode for å prøve å reversere endringene. Så hvis du vurderer å slette data fra databasen, vær ekstra forsiktig. Disse typer endringer er vanskelig å angre. Andre endringer som er vanskelige å reversere, inkluderer å gi nytt navn til kolonner og endre datatypen for en kolonne som allerede inneholder data. En tommelfingerregel jeg liker å gå med er dette: du bør nesten aldri slette kolonner til neste store (du vet semver, ikke sant?) utgitt. Denne regelen gjelder selv om jeg har kolonner jeg vil slutte å bruke. I stedet for å slette kolonner, vil jeg kunngjøre i de mindre versjonene hvilke kolonner som vil bli avskrevet fremover. Når det kommer tid for en stor utgivelse, vil jeg da slippe disse kolonnene helt. På den måten reduserer jeg sjansene for å utføre en utilsiktet, uønsket endring som vil være en forferdelig prosess å reversere for hånd.
Implementer Funksjonsflagg
en annen utmerket strategi for databaseoverføring er å implementere funksjonsflagg, spesielt når du har et stort lag og flere personer prøver å implementere forskjellige funksjoner for samme kodebase. Ifølge Martin Fowler, har flagg er » en kraftig teknikk, slik at lagene til å endre systematferd uten å endre kode.»Faktisk, jo større teamet ditt og jo mer komplisert kodebasen din er, jo flere funksjonsflagger skinner. Funksjonsflagg bidrar til å redusere risikoen når det gjelder databaseoverføringer. Å prøve å løsne endringene når du trenger å rulle tilbake visse funksjoner, kan være et ekte mareritt. Feature flagg fungerer like bra om du ønsker å gjøre små eller store databaseskjema endringer. Når du bruker funksjonsflagg, anbefaler jeg at du tar sikte på hyppigere og granulære endringer generelt. Og du kan virkelig se hvordan funksjonen flagg hjelpe utviklingsprosessen når du utfører en massiv skjema endring. Vennligst fortsatt sikte på å bryte denne massive skjema endring i mindre, tynne skiver. Du trenger ikke å imponere noen med hvor mye du kan presse i en endring. Bedre å legge til garantier for utviklingspraksis ved å implementere alle tre anbefalingene jeg har snakket om i denne delen.
Konklusjon
Utviklere trenger alle verktøyene de kan få for å gjøre livet enklere. Database migrasjon er en av de må-ha verktøy for utviklerens verktøykasse. Fremover, jeg forutse at ansette database vandringer vil utvikle seg fra en utvikling beste praksis til en utvikling standard praksis. Folk vil se på deg morsomt for ikke å bruke database migrasjon i det hele tatt. Likevel er det viktig å huske på hvordan databaseoverføringer kan slå tilbake på deg, spesielt for vanskelig å reversere skjemaendringer. Vær helt sikker på disse endringene før du gjør dem gå live. Hvis du ikke allerede bruker databaseoverføring i prosessen, hva venter du på? Det er lett å starte, og du kan til og med legge det til midtveis i utviklingssyklusen. Du vil være takknemlig du gjorde. Fordi når dagen kommer at du må rulle tilbake endringene og endringene involverer databasen, vil du ønske at du hadde noe å hjelpe deg med å gjøre det på bare sekunder. Database migrasjon er at noe du ønsker du hadde.