ungefär samtidigt blev Git populär, trenden för att skriva webbaserade applikationer med hjälp av OBJEKTRELATIONELL kartläggning (ORM) bibliotek blev också välkänd. Nyckeltanken var detta: eftersom utvecklare kan göra ändringar i kod som är lätta att rulla tillbaka med Git, varför kan inte Utvecklare göra samma sak när det gäller schemaändringar? När allt kommer omkring innebär en rimlig ny funktion kod-och schemaändringar. Så populära ramar som Rails och Django lagt ORM och databas migration (även känd som schema migration) som en del av sina erbjudanden. Men databasmigrering som koncept är inte begränsat till populära webbramar. Det finns även fristående bibliotek databas migration programvara som Flyway och Liquibase. Kan du tänka dig att kunna rulla tillbaka granulära ändringar i schemat när du skriver din kod? Alltför ofta tycker jag att artiklar om databasmigrering inte diskuterar vad det innebär att aktivt göra en, som utvecklare. Jag vill rätta till det här. Med det i åtanke kommer jag idag att ge dig den stora bilden av vad databasmigrering innebär och hur man gör det i en aktiv utvecklingsmiljö. Jag ska dela upp detta i tre sektioner, som täcker vad som händer under migrationsprocessen, de vanliga verktygen som används och de fallgropar som kan dyka upp under databasmigrering. Detta bör ge en nybörjare verktyg för att snabbt lära sig de viktigaste tankarna bakom datamigrering och även lära sig potentiella fallgropar att undvika när man använder databasmigrering som en del av hans eller hennes utvecklingsverktygslåda.
Vad Händer Under Databasmigrering?
nu när du vet hur databasmigreringar kom till, Låt mig gå igenom vad de faktiskt innebär.
granulära ändringar genereras som enskilda skriptfiler
jag nämnde hur databasmigreringar i princip spårar granulära ändringar i ditt databasschema (och ibland också till dina data). Dessa granulära förändringar återspeglas vanligtvis som separata skriptfiler. På så sätt återspeglas dina granulära schemaändringar som kod som kan fångas med vilken versionshanteringsprogramvara som helst. Detta är ett exempel 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
inte bara kan du ha migreringar som fristående filer, du kan också ha det aktuella databasschemat som sin egen fil. Vanligtvis är detta känt som en schemafil.
Databasmigreringsskript är Verktygsberoende
hämta databasmigreringsskriptet i Ruby från vårt tidigare exempel. Här är en annan databasmigreringsfil från den oberoende källkontrollen för databasprogramvaran 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>
den här gången är filen i XML-format. I själva verket kan Liquibase producera migreringsändringar (eller ändringsuppsättningar, som de vill kalla dem) i flera format som XML och JSON. Så om du inte vill skriva din databasmigrering i SQL-format finns det inga riktiga standarder för hur migreringsfilerna skapas. Naturligtvis kan du skriva dina egna anpassade databasmigreringsskript i SQL-filerna. Men varför handwrite och oavsiktligt införa buggar när du kan använda verktyg för att autogenerera databas migreringar?
hur utför du en databasmigrering?
nu vet du vad en databasmigrering är. Du måste också veta (åtminstone konceptuellt) hur man utför en databasmigrering. Tyvärr finns det inga standarder alls för databasmigreringsfiler, vilket innebär att vi inte kan komma in för mycket detaljer om hur man skapar dem. Med andra ord, hur du utför en databasmigrering beror starkt på det specifika verktyget du använder för aktiviteten. I det här avsnittet täcker jag de två vanligaste sätten att utföra en databasmigrering.
alternativ 1: Använd ett ramverk/språkberoende Bibliotek
om du använder ett populärt språk (Ruby, PHP, Python, etc.) eller ramverk (Rails, Django, etc.), då finns det väldokumenterade bibliotek för datamigrering inom universum för det valda ramverket/språket. De populära webbramarna kommer naturligtvis att levereras med databasmigreringsfunktionerna. Beroende på inställningen kan du till och med byta ut den ursprungliga databasmigreringen för andra bibliotek inom det valda språket. I det här scenariot genererar du vanligtvis migreringsfilerna med kommandoraden. Ibland kan du behöva skriva den anpassade koden för vissa ändringar, till exempel datamigrering eller till och med hur du ändrar själva ändringen. Utöver det tar biblioteket som valts inom ramen/språket ganska mycket hand om detta åt dig.
alternativ 2: Använd oberoende Databasmigreringsfokuserad programvara
i vissa fall vill du använda programvara som Flyway eller Liquibase som bara fungerar som en källkontroll för din databas. Genom att göra detta undviker du att vara låst i ett visst ramverk eller språk. Det betyder inte att du har noll inlåsning. Ta till exempel Flyway, som fungerar bra med olika databaser som Oracle, MySQL och MariaDB. Om du inte använder Flyways Java – baserade migrering (som låser dig i Java och Flyway) kan du sluta använda SQL-baserad migrering (som låser dig till ditt val av databas och Flyway). Den goda nyheten är Flyway och Liquibase är båda relativt enkla att använda. De ger också en kommandorad sätt att generera migreringar och tillåta anpassad kodning för att fånga databasschemat migreringar.
att välja det bästa alternativet för dig
här är min åsikt om att välja mellan båda alternativen. Jag brukar se att de flesta utvecklare väljer alternativ 1. Vanligtvis beror det på att utvecklare redan har ett föredraget språk/ramverk, så kognitivt sett känns det inte som att de lär sig (ännu) en annan programvara. Och inlåsningen (i fallet med alternativ 1 skulle detta vara till ramverket och språket) är helt frivilligt och önskat. Du kan göra fallet för alternativ 2 om ditt team inte helt har engagerat sig i ett visst språk eller ramverk. Oavsett vad du går för, undvik att ändra ditt val onödigt halvvägs genom utveckling. Databasmigrering är inte ett område där byte av verktyg ger dig enorma fördelar. De flesta av fördelarna kommer från att helt enkelt ha databasmigrering inrättad i första hand.
farorna med databasmigrering och hur man undviker dem
i föregående avsnitt täckte jag de två huvudtyperna av verktyg för databasmigrering: ramverk/språkberoende och fristående programvara. Båda typerna är lätta att använda. Nu rekommenderar jag tre bästa metoder när det gäller att faktiskt utföra en databasmigrering. Dessa tips behandlar den största risken för databasmigrering: du vill undvika att göra oåterkalleliga ändringar.
Välj ett Databasmigreringsverktyg och håll fast vid det
jag nämnde detta kort tidigare, men det är värt att betona: jag vill varna för att göra onödiga ändringar i verktygsuppsättningen helt enkelt för att det är coolt. Kom ihåg att databasmigreringsskript är beroende av det verktyg du använder för att generera dem. Det finns inga riktiga standarder för dessa skript. Om du verkligen vill kan du till och med skriva din egen i SQL-satser. Det introducerar sin egen uppsättning problem; till exempel kan dina SQL-skript sannolikt vara databasberoende. MySQL-frågor kanske inte fungerar i PostgreSQL och vice versa. Så antingen är du låst i ditt databasmigreringsverktyg, eller så är du låst i ditt val av Databas—eller i vissa fall, även båda. Det finns inga uppenbara fördelar med att byta verktygsuppsättning ofta, så mitt förslag är att välja ett databasmigreringsverktyg och hålla fast vid det. Det finns bättre saker att göra med din tid än att snurra hjulen i onödan.
ta bara bort rader eller kolumner när du är helt säker på att du behöver
när det gäller migreringar kan du för det mesta vända dem när du behöver. Typiska databasmigreringsverktyg kan hantera enkla reversibla förändringar. Och även när de inte kan kan du enkelt lägga till din egen anpassade kod för att hjälpa till med att vända. Till exempel i Rails lägger du helt enkelt till 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åraste ändringarna att vända tenderar att innebära att du tar bort saker: specifikt raderar kolumner eller rader med data. Om din databas innehåller mycket data kan du behöva skriva en betydande mängd anpassad kod för att försöka vända dina ändringar. Så om du funderar på att ta bort data från din Databas, var extra försiktig. Dessa typer av förändringar är svåra att ångra. Andra svåra att vända ändringar inkluderar att byta namn på Kolumner och ändra datatypen för en kolumn som redan innehåller data. En tumregel som jag gillar att gå med är detta: du borde nästan aldrig ta bort kolumner till nästa major (du vet semver, eller hur?) utgåva. Denna regel gäller även om jag har kolumner som jag vill sluta använda. I stället för att radera kolumner meddelar jag i de mindre versionerna vilka kolumner som kommer att avvecklas framöver. När det är dags för en stor release, jag kommer då att släppa dessa kolumner helt. På så sätt minskar jag chansen att utföra en oavsiktlig, oönskad förändring som kommer att vara en hemsk process att vända för hand.
implementera Funktionsflaggor
en annan utmärkt strategi för databasmigrering är att implementera funktionsflaggor, särskilt när du har ett stort team och flera personer försöker implementera olika funktioner för samma kodbas. Enligt Martin Fowler är funktionsflaggor ” en kraftfull teknik som gör det möjligt för lag att ändra systembeteende utan att ändra kod.”Faktum är att ju större ditt lag och ju mer komplex din kodbas är, desto fler funktionsflaggor lyser. Funktionsflaggor hjälper till att mildra risken när det gäller databasmigreringar. Att försöka ta bort förändringarna när du behöver rulla tillbaka vissa funktioner kan vara en riktig mardröm. Funktionsflaggor fungerar lika bra om du vill göra små eller stora databasschemaändringar. När du använder funktionsflaggor rekommenderar jag att du strävar efter mer frekventa och granulära förändringar totalt sett. Och du kan verkligen se hur funktionsflaggor hjälper din utvecklingsprocess när du utför en massiv schemaändring. Vänligen fortfarande syftar till att bryta denna massiva schema förändring i mindre, tunna skivor. Du behöver inte imponera på någon med hur mycket du kan klämma i en förändring. Bättre att lägga till skyddsåtgärder för dina utvecklingsmetoder genom att genomföra alla tre rekommendationer som jag har pratat om i det här avsnittet.
slutsats
utvecklare behöver alla verktyg de kan få för att göra livet enklare. Databasmigrering är ett av dessa måste-ha verktyg för utvecklarens verktygslåda. Framöver förutser jag att användningen av databasmigreringar kommer att utvecklas från en bästa praxis för utveckling till en standardpraxis för utveckling. Folk kommer att titta på dig roligt för att inte använda databasmigrering alls. Ändå är det viktigt att komma ihåg hur databasmigreringar kan slå tillbaka på dig, särskilt för svåra att vända schemaändringar. Var helt säker på dessa förändringar innan du gör dem gå live. Om du inte redan använder databasmigrering i din process, vad väntar du på? Det är lätt att börja, och du kan till och med lägga till det halvvägs genom din utvecklingscykel. Du kommer att vara tacksam att du gjorde det. För när dagen kommer att du behöver rulla tillbaka dina ändringar och ändringarna involverar databasen, önskar du att du hade något som hjälper dig att göra det på bara några sekunder. Databas migration är att något du önskar att du hade.