körülbelül ugyanebben az időben a Git népszerűvé vált, az object-relational mapping (ORM) könyvtárakat használó webalapú alkalmazások írásának trendje is ismertté vált. A legfontosabb ötlet a következő volt: mivel a fejlesztők olyan kódmódosításokat hajthatnak végre, amelyeket a Git segítségével könnyen vissza lehet állítani, miért nem tehetik meg ugyanezt a fejlesztők a sémamódosításokkal kapcsolatban? Végül is minden ésszerű új funkció magában foglalja a kód és a séma módosítását. Az olyan népszerű keretrendszerek, mint a Rails és a Django, ORM és database migrációt (más néven séma migrációt) adtak a kínálatuk részeként. Az adatbázis-migráció mint fogalom azonban nem korlátozódik a népszerű webes keretrendszerekre. Vannak még önálló adatbázis-migrációs szoftverkönyvtárak, mint a Flyway és a Liquibase. El tudja képzelni, hogy a kód írása közben vissza tudja állítani a séma szemcsés módosításait? Túl gyakran találom, hogy az adatbázis-migrációról szóló cikkek nem tárgyalják, mit jelent aktívan csinálni, mint Fejlesztő. Ezt itt szeretném kijavítani. Ezt szem előtt tartva ma átfogó képet adok arról, hogy mit jelent az adatbázis-migráció, és hogyan kell ezt megtenni egy aktív fejlesztési környezetben. Ezt három részre bontom, amelyek lefedik, hogy mi történik az áttelepítési folyamat során, a használt általános eszközöket, valamint az adatbázis-áttelepítés során felbukkanó buktatókat. Ez kell adni egy kezdő fejlesztő az eszközöket, hogy gyorsan megtanulják a legfontosabb ötleteket mögött adatmigráció, valamint megtanulják a lehetséges buktatókat, hogy elkerüljék, ha az adatbázis migráció részeként ő fejlesztési eszköztár.
Mi Történik Az Adatbázis-Áttelepítés Során?
most, hogy tudod, hogy az adatbázis-migráció hogyan jött létre, hadd mutassam meg, mit jelentenek valójában.
a szemcsés változások egyedi szkriptelt fájlokként jönnek létre
említettem, hogy az adatbázis-migrációk alapvetően nyomon követik az adatbázis-séma (és néha az adatok) szemcsés változásait. Ezek a szemcsés változások általában különálló szkriptelt fájlokként jelennek meg. Így a szemcsés sémaváltozások olyan kódként jelennek meg, amelyet bármilyen verziókezelő szoftverrel rögzíthet. Ez egy példa a Rails migrációs fájljára.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
nem csak akkor van migrációk önálló fájlokat, akkor is van az aktuális adatbázis séma, mint a saját fájl. Ez általában sémafájl néven ismert.
az adatbázis-áttelepítési parancsfájlok Eszközfüggőek
idézzük fel az adatbázis-áttelepítési parancsfájlt Ruby-ban a korábbi példánkból. Itt van egy másik adatbázis-áttelepítési fájl a Liquibase adatbázis-szoftver független forrásvezérlőjéből.
<?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>
ezúttal a fájl XML formátumban van. Valójában a Liquibase képes migrációs változásokat (vagy változókészleteket, ahogy ők nevezik őket) többféle formátumban, például XML és JSON. Tehát, hacsak nem akarja kézzel írni az adatbázis-áttelepítést SQL formátumban, nincsenek valódi szabványok az áttelepítési fájlok létrehozásának módjára vonatkozóan. Természetesen, akkor írj a saját egyéni adatbázis migrációs szkriptek az SQL fájlokat. De miért írna kézzel és vezetne be véletlenül hibákat, amikor eszközöket használhat az adatbázis-migrációk automatikus generálására?
hogyan hajthat végre Adatbázis-migrációt?
most már tudja, mi az adatbázis-migráció. Azt is tudnia kell (legalábbis fogalmilag), hogyan kell végrehajtani az adatbázis-migrációt. Sajnos az adatbázis-áttelepítési fájlokra egyáltalán nincsenek szabványok, ami azt jelenti, hogy nem tudunk túl sok részletbe belemenni a létrehozásuk módjáról. Más szavakkal, az adatbázis-áttelepítés végrehajtásának módja nagymértékben függ a feladathoz használt eszköztől. Ebben a szakaszban kitérek az adatbázis-áttelepítés végrehajtásának két leggyakoribb módjára.
1.Lehetőség: használjon keretrendszert/Nyelvfüggő könyvtárat
ha népszerű nyelvet használ (Ruby, PHP, Python stb.) vagy keretrendszer (sínek, Django stb.), akkor vannak jól dokumentált könyvtárak az adatmigrációhoz a választott keretrendszer/nyelv univerzumán belül. A népszerű webes keretrendszerek természetesen az adatbázis-migrációs funkciókkal együtt érkeznek. A beállítástól függően akár a natív adatbázis-migrációt is kicserélheti más könyvtárakra a kiválasztott nyelven belül. Ebben az esetben általában a parancssor segítségével hozza létre az áttelepítési fájlokat. Előfordulhat, hogy kézzel kell írnia az egyéni kódot néhány változtatáshoz, például az adatok áttelepítéséhez vagy akár magának a változásnak a visszafordításához. Más, mint, hogy a könyvtár belül kiválasztott keret / nyelv nagyjából gondoskodik erről az Ön számára.
2.lehetőség: használjon független adatbázis-migrációra összpontosító szoftvert
bizonyos esetekben olyan szoftvereket szeretne használni, mint a Flyway vagy a Liquibase, amelyek csak az adatbázis forrásvezérlőjeként működnek. Ezzel elkerülheti, hogy bezáródjon egy adott keretbe vagy nyelvbe. Ez nem azt jelenti, hogy nulla zár van. Vegyük például a Flyway-t, amely jól működik különböző adatbázisokkal, mint például az Oracle, a MySQL és a MariaDB. Ha nem használja a Flyway Java-alapú migrációját (amely lezárja a Java-t és a Flyway-t), akkor az SQL-alapú migrációt használhatja (amely zárolja az adatbázis és a Flyway kiválasztását). A jó hír az, hogy a Flyway és a Liquibase egyaránt viszonylag könnyen használható. Parancssori módot is biztosítanak az áttelepítések generálására, és lehetővé teszik az egyéni kódolást az adatbázis séma áttelepítéseinek rögzítésére.
a legjobb választás az Ön számára
itt van a véleményem a választás között bármelyik lehetőség. Általában azt látom, hogy a legtöbb fejlesztő az 1. lehetőséget választja. Általában ez azért van, mert a fejlesztőknek már van egy preferált nyelvük/keretrendszerük, így kognitív szempontból nem érzi úgy, hogy (még) egy másik szoftvert tanulnak. És a zárolás (az 1.lehetőség esetében ez a keretrendszerre és a nyelvre vonatkozna) teljesen önkéntes és kívánatos. A 2. lehetőség mellett érvelhet, ha csapata nem kötelezte el magát teljes mértékben egy adott nyelv vagy keretrendszer mellett. Bármelyiket is választja, kerülje a választás szükségtelen megváltoztatását a fejlesztés közepén. Az adatbázis-migráció nem olyan terület, ahol az eszközök megváltoztatása óriási előnyökkel jár. A legtöbb előny abból származik, hogy egyszerűen adatbázis-migrációt állítottak fel.
az adatbázis-migráció veszélyei és azok elkerülése
az előző részben az adatbázis-migráció eszközeinek két fő típusával foglalkoztam: keretrendszer/nyelvfüggő és önálló szoftver. Mindkét típus könnyen használható. Most három legjobb gyakorlatot ajánlok, amikor az adatbázis-migráció tényleges végrehajtásáról van szó. Ezek a tippek az adatbázis-migráció fő veszélyével foglalkoznak: el akarja kerülni a visszafordíthatatlan változtatásokat.
válasszon ki egy adatbázis-áttelepítési eszközt, és ragaszkodjon hozzá
ezt már röviden említettem korábban, de érdemes hangsúlyozni: figyelmeztetni szeretném, hogy ne végezzen felesleges változtatásokat az eszközkészleten, csak azért, mert klassz. Emlékezzünk arra, hogy az adatbázis-áttelepítési parancsfájlok a létrehozásukhoz használt eszköztől függenek. Nincs megfelelő szabvány ezekre a szkriptekre. Ha igazán szeretné, akkor is írhat saját SQL utasításokat. Ez bemutatja a saját problémakészletét; például az SQL szkriptek valószínűleg adatbázisfüggőek lehetnek. Előfordulhat, hogy a MySQL lekérdezések nem működnek a PostgreSQL-ben, és fordítva. Tehát vagy be van zárva az adatbázis-áttelepítési eszközbe, vagy be van zárva a választott adatbázisba—vagy bizonyos esetekben akár mindkettőbe. Nincs nyilvánvaló előnye az eszközkészlet gyakori váltásának, ezért azt javaslom, hogy válasszon egy adatbázis-migrációs eszközt, és ragaszkodjon hozzá. Vannak jobb dolgok az időddel, mint feleslegesen forgatni a kerekeket.
csak akkor törölhet sorokat vagy oszlopokat, ha teljesen biztos benne, hogy
amikor migrációkról van szó, nagyrészt megfordíthatja őket, amikor szüksége van rá. A tipikus adatbázis-áttelepítési eszközök képesek kezelni az egyszerű reverzibilis változásokat. És még akkor is, ha nem tudják, könnyen hozzáadhatja saját egyéni kódját, hogy segítsen a hátramenetben. Például a Rails – ben egyszerűen hozzáadja a kódot a reverzibilis alatt.
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
a legnehezebben visszafordítható változtatások általában a dolgok törlésével járnak: konkrétan oszlopok vagy adatsorok törlésével. Ha az adatbázis sok adatot tartalmaz, előfordulhat, hogy jelentős mennyiségű egyéni kódot kell írnia a módosítások visszafordításához. Tehát, ha fontolóra veszi az adatok törlését az adatbázisból, legyen különösen óvatos. Az ilyen típusú változásokat nehéz visszavonni. Más nehezen visszafordítható változások közé tartozik az oszlopok átnevezése és egy olyan oszlop adattípusának módosítása, amely már tartalmaz adatokat. Az egyik ökölszabály, amellyel szeretek menni, ez: szinte soha nem szabad törölni az oszlopokat a következő főig (tudod semver, igaz?) kiadás. Ez a szabály akkor is érvényes, ha vannak olyan oszlopaim, amelyeket le akarok állítani. Az oszlopok törlése helyett a kisebb verziókban bejelentem, hogy mely oszlopok lesznek elavultak a jövőben. Amikor eljön az ideje egy nagyobb kiadásnak, akkor ezeket az oszlopokat teljesen eldobom. Így csökkentem a véletlen, nem kívánt változás végrehajtásának esélyét, amelyet szörnyű folyamat lesz kézzel visszafordítani.
implement Feature Flags
az adatbázis-áttelepítés másik kiváló stratégiája a feature flags implementálása, különösen akkor, ha egy nagy csapat és több ember próbál különböző funkciókat implementálni ugyanarra a kódbázisra. Martin Fowler szerint a feature flags ” hatékony technika, amely lehetővé teszi a csapatok számára, hogy a kód megváltoztatása nélkül módosítsák a rendszer viselkedését.”Valójában minél nagyobb a csapatod és annál összetettebb a kódbázisod, annál több funkciós zászló ragyog. Feature zászlók segít csökkenteni a kockázatot, amikor az adatbázis migráció. Valódi rémálom lehet, ha megpróbálja kibontani a változásokat, amikor bizonyos funkciókat vissza kell állítania. Feature zászlók ugyanolyan jól működik, hogy azt szeretnénk, hogy a kis vagy nagy adatbázis séma változások. A feature zászlók használatakor azt javaslom, hogy törekedjen a gyakoribb és szemcsés változásokra. És valóban láthatja, hogy a funkciójelzők hogyan segítik a fejlesztési folyamatot, amikor hatalmas sémaváltást hajt végre. Kérjük, továbbra is törekedjen arra, hogy ezt a hatalmas sémaváltást kisebb, vékony szeletekre bontsa. Nem kell senkit lenyűgöznie azzal, hogy mennyit tud megszorítani egy változás során. Jobb, ha biztosítékokat ad a fejlesztési gyakorlatához azáltal, hogy végrehajtja mind a három ajánlást, amelyekről ebben a szakaszban beszéltem.
következtetés
a fejlesztőknek minden eszközre szükségük van, hogy megkönnyítsék az életüket. Az adatbázis-migráció a fejlesztő eszközkészletének egyik kötelező eszköze. Előre látni, hogy az adatbázis-migrációk alkalmazása a fejlesztési legjobb gyakorlattól a fejlesztési standard gyakorlatig fog fejlődni. Az emberek viccesen fognak rád nézni, hogy egyáltalán nem használod az adatbázis-migrációt. Ennek ellenére fontos szem előtt tartani, hogy az adatbázis-migrációk hogyan tudnak visszaütni rád, különösen a nehezen visszafordítható sémaváltozások esetén. Legyen teljesen biztos ezekben a változásokban, mielőtt életbe léptetné őket. Ha még nem használja az adatbázis-migrációt a folyamatban, mire vár? Könnyű elindítani, sőt a fejlesztési ciklus közepén is hozzáadhatja. Hálás leszel, hogy megtetted. Mert amikor eljön a nap, hogy vissza kell állítania a változtatásokat, és a változások az adatbázist érintik, azt kívánja, bárcsak lenne valami, ami segít abban, hogy néhány másodperc alatt megtegye. Az adatbázis-migráció az, amit szeretne.