přibližně ve stejné době se Git stal populárním, trend pro psaní webových aplikací pomocí knihoven objektově relačního mapování (ORM) se také stal známým. Klíčová myšlenka byla tato: protože vývojáři mohou provádět změny v kódu, které lze snadno vrátit zpět pomocí Git, proč nemohou vývojáři dělat totéž, pokud jde o změny schématu? Koneckonců, každá rozumná nová funkce zahrnuje změny kódu a schématu. Populární rámce jako Rails a Django přidaly ORM a migraci databází (také známou jako migrace schémat) jako součást svých nabídek. Migrace databází jako koncept se však neomezuje pouze na populární webové rámce. Existují dokonce samostatné knihovny softwaru pro migraci databází, jako jsou Flyway a Liquibase. Dokážete si představit, že budete moci vrátit granulární změny schématu při psaní kódu? Příliš často, zjistil jsem, že články o migraci databází nediskutují o tom, co to znamená aktivně dělat, jako vývojář. Chci to napravit. S ohledem na to vám dnes poskytnu rozsáhlý pohled na to, co migrace databáze zahrnuje a jak to udělat v aktivním vývojovém prostředí. Rozdělím to do tří částí, pokrývající to, co se děje během procesu migrace, běžné použité nástroje, a úskalí, která se mohou objevit během migrace databáze. To by mělo dát začátečník developer nástroje rychle naučit klíčové myšlenky migrace dat a také naučit potenciální úskalí, aby se zabránilo při použití databáze migrace jako součást jeho nebo její vývoj toolbox.
Co Se Stane Během Migrace Databáze?
Nyní, když víte, jak došlo k migraci databází, dovolte mi, abych vás provedl tím, co ve skutečnosti znamenají.
granulární změny jsou generovány jako jednotlivé skriptované soubory
zmínil jsem se, jak migrace databází v podstatě sledují granulární změny ve schématu databáze(a někdy i ve vašich datech). Tyto granulární změny se obvykle odrážejí jako samostatné skriptované soubory. Tímto způsobem se vaše granulární změny schématu projeví jako kód, který lze zachytit pomocí libovolného softwaru pro správu verzí. Toto je příklad migračního souboru v Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
nejen, že můžete mít migrace jako samostatné soubory, můžete mít také aktuální schéma databáze jako vlastní soubor. Obvykle se to nazývá soubor schématu.
skripty pro migraci databáze jsou závislé na nástroji
Připomeňme skript pro migraci databáze v Ruby z našeho dřívějšího příkladu. Zde je další soubor migrace databáze z nezávislého řízení zdroje pro databázový software 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>
Tentokrát je soubor ve formátu XML. Ve skutečnosti může Liquibase vytvářet migrační změny (nebo sady změn, jak jim rádi říkají) ve více formátech, jako jsou XML a JSON. Pokud tedy nechcete ručně psát migraci databáze ve formátu SQL, neexistují žádné skutečné standardy v tom, jak jsou migrační soubory vytvářeny. Samozřejmě můžete do souborů SQL psát vlastní skripty pro migraci databáze. Ale proč ručně psát a náhodně zavádět chyby, když můžete využít nástroje k autogeneraci migrací databáze?
jak provádíte migraci databáze?
nyní víte, co je migrace databáze. Musíte také vědět (alespoň koncepčně), jak provést migraci databáze. Bohužel neexistují žádné standardy pro soubory migrace databází, což znamená, že se nemůžeme dostat do příliš podrobností o tom, jak je vytvořit. Jinými slovy, způsob provádění migrace databáze do značné míry závisí na konkrétním nástroji, který pro danou úlohu používáte. V této části se budu zabývat dvěma nejčastějšími způsoby provádění migrace databáze.
Možnost 1: Použijte knihovnu závislou na frameworku/jazyce
, pokud používáte populární jazyk (Ruby, PHP, Python atd.) nebo rámec (kolejnice, Django atd.), pak existují dobře zdokumentované knihovny pro migraci dat ve vesmíru zvoleného rámce / jazyka. Populární webové rámce budou přirozeně dodávány s funkcemi migrace databáze. V závislosti na Nastavení můžete dokonce vyměnit nativní migraci databáze za jiné knihovny ve zvoleném jazyce. Typicky v tomto scénáři generujete migrační soubory pomocí příkazového řádku. Občas budete možná muset ručně napsat vlastní kód pro některé změny, jako je Migrace dat nebo dokonce jak zvrátit samotnou změnu. Kromě toho se o to stará knihovna vybraná v rámci / jazyce.
možnost 2: Použijte nezávislý software zaměřený na migraci databáze
v některých případech budete chtít použít software jako Flyway nebo Liquibase, který slouží pouze jako zdrojová kontrola vaší databáze. Tímto způsobem se vyhnete uzamčení do určitého rámce nebo jazyka. To neznamená, že máte nulový lock-in. Vezměte si například Flyway, který dobře funguje s různými databázemi, jako jsou Oracle, MySQL a MariaDB. Pokud nepoužíváte migraci založenou na Java Flyway (která vás uzamkne do Java a Flyway), můžete skončit pomocí migrace založené na SQL (která vás uzamkne při výběru databáze a Flyway). Dobrou zprávou je, Flyway a Liquibase jsou oba relativně snadno použitelné. Také poskytují způsob příkazového řádku pro generování migrací a umožňují vlastní kódování pro zachycení migrací schématu databáze.
výběr nejlepší možnosti pro vás
zde je můj názor na výběr mezi oběma možnostmi. Mám tendenci vidět, že většina vývojářů volí možnost 1. Obvykle je to proto, že vývojáři již mají preferovaný jazyk / rámec, takže kognitivně řečeno, nemá pocit, že se učí (zatím) další kus softwaru. A uzamčení (v případě možnosti 1 by to bylo do rámce a jazyka) je zcela dobrovolné a žádoucí. Můžete použít možnost 2, pokud se Váš tým plně nezavázal k určitému jazyku nebo rámci. Bez ohledu na to, pro co jdete, vyhněte se zbytečné změně výběru v polovině vývoje. Migrace databáze není oblast, kde změna nástrojů přináší obrovské výhody. Většina výhod pochází z pouhého nastavení migrace databáze.
nebezpečí migrace databáze a jak se jim vyhnout
v předchozí části jsem se zabýval dvěma hlavními typy nástrojů pro migraci databáze: framework / language-dependent a samostatný software. Oba typy se snadno používají. Nyní doporučím tři osvědčené postupy, pokud jde o skutečné provedení migrace databáze. Tyto tipy řeší hlavní nebezpečí migrace databáze: chcete se vyhnout nevratným změnám.
vyberte jeden nástroj pro migraci databáze a držte se ho
zmínil jsem se o tom krátce dříve, ale stojí za to zdůraznit: chci varovat před zbytečnými změnami sady nástrojů jednoduše proto, že je to v pohodě. Připomeňme, že skripty pro migraci databáze jsou závislé na nástroji, který používáte k jejich generování. Pro tyto skripty neexistují žádné správné standardy. Pokud opravdu chcete, můžete dokonce napsat vlastní příkazy SQL. To představuje vlastní sadu problémů; například vaše skripty SQL budou pravděpodobně závislé na databázi. MySQL dotazy nemusí fungovat v PostgreSQL a naopak. Takže buď jste uzamčeni do nástroje pro migraci databáze, nebo jste uzamčeni do výběru databáze-nebo v některých případech dokonce obojí. Přepínání sady nástrojů často nemá žádné zjevné výhody, takže můj návrh je vybrat jeden nástroj pro migraci databáze a držet se ho. Jsou lepší věci na práci s vaším časem, než zbytečně točit kola.
Smazat řádky nebo sloupce pouze tehdy, když jste si naprosto jisti, že potřebujete
pokud jde o migrace, z větší části je můžete obrátit, když potřebujete. Typické nástroje pro migraci databází zvládnou jednoduché reverzibilní změny. A i když nemohou, můžete snadno přidat svůj vlastní kód, který vám pomůže s couváním. Například v Rails jednoduše přidáte kód pod reverzibilní.
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
nejtěžší změny, které lze zvrátit, mají tendenci zahrnovat mazání věcí: konkrétně mazání sloupců nebo řádků dat. Pokud vaše databáze obsahuje velké množství dat, můžete nakonec napsat značné množství vlastního kódu, abyste se pokusili zvrátit změny. Pokud tedy uvažujete o vymazání dat z databáze, buďte zvlášť opatrní. Tyto typy změn je těžké vrátit zpět. Mezi další těžko obrácené změny patří přejmenování sloupců a změna datového typu sloupce, který již obsahuje data. Jedno pravidlo, se kterým rád chodím, je toto: téměř nikdy byste neměli mazat sloupce až do dalšího hlavního (znáte semvera, že?) vydat. Toto pravidlo platí, i když mám sloupce, které chci přestat používat. Místo mazání sloupců oznámím v menších verzích, které sloupce budou do budoucna zastaralé. Až přijde čas na velké vydání, pak tyto sloupce úplně upustím. Tímto způsobem snižuji šance na provedení náhodné, nežádoucí změny, která bude hrozným procesem zvrátit ručně.
implementujte příznaky funkcí
další vynikající strategií pro migraci databází je implementace příznaků funkcí, zejména pokud máte velký tým a více lidí se snaží implementovat různé funkce pro stejnou kódovou základnu. Podle Martina Fowlera jsou příznaky funkcí “ výkonnou technikou, která umožňuje týmům měnit chování systému bez změny kódu.“Ve skutečnosti, čím větší je váš tým a čím složitější je vaše kódová základna, tím více vlajek funkcí svítí. Příznaky funkcí pomáhají zmírnit riziko, pokud jde o migraci databází. Pokoušet se rozmotat změny, když potřebujete vrátit určité funkce, může být skutečnou noční můrou. Příznaky funkcí fungují stejně dobře, ať už chcete provádět malé nebo velké změny schématu databáze. Při používání příznaků funkcí doporučujeme zaměřit se na častější a podrobnější změny celkově. A můžete opravdu vidět, jak funkce příznaky pomoci procesu vývoje při provádění masivní změnu schématu. Snažte se tuto masivní změnu schématu rozdělit na menší, tenké plátky. Nemusíte nikoho ohromovat tím, kolik můžete v jedné změně zmáčknout. Je lepší přidat do svých vývojových postupů ochranná opatření implementací všech tří doporučení, o kterých jsem hovořil v této části.
závěr
vývojáři potřebují všechny nástroje, které mohou získat, aby usnadnili svůj život. Migrace databáze je jedním z těch nástrojů, které musíte mít pro vývojářskou sadu nástrojů. Do budoucna, předpokládám, že zaměstnávání databázových migrací se bude vyvíjet z osvědčených postupů pro vývoj na standardní postup pro vývoj. Lidé se na vás budou dívat vtipně, že vůbec nepoužíváte migraci databáze. Přesto je důležité mít na paměti, jak migrace databáze může selhat na vás, zejména pro těžko zvrátit změny schématu. Buďte si těmito změnami naprosto jisti, než je uvedete do provozu. Pokud ve svém procesu ještě nepoužíváte migraci databáze, na co čekáte? Je to snadné začít, a dokonce můžete přidat v polovině svého vývojového cyklu. Budeš vděčný, že jsi to udělal. Protože když přijde den, že budete muset vrátit zpět své změny a změny se týkají databáze, budete si přát, abyste měli něco, co vám pomůže udělat to za pouhé sekundy. Migrace databáze je něco, co si budete přát, abyste měli.