samoihin aikoihin kun Git sai suosiota, tuli tunnetuksi myös suuntaus web-pohjaisten sovellusten kirjoittamiseen object-relational mapping (ORM) – kirjastojen avulla. Keskeinen idea oli tämä: koska kehittäjät voivat tehdä koodiin muutoksia, jotka on helppo palauttaa Gitin avulla, miksi kehittäjät eivät voisi tehdä samaa skeemamuutosten suhteen? Loppujen lopuksi jokainen järkevä uusi ominaisuus sisältää koodin ja skeeman muutoksia. Niin suosittuja kehyksiä, kuten Rails ja Django lisätty ORM ja tietokanta muuttoliike (tunnetaan myös nimellä skeema muuttoliike) osana tarjontaansa. Mutta tietokannan muuttoliike käsitteenä ei rajoitu suosittuihin web-kehyksiin. On jopa itsenäinen tietokanta muuttoliike ohjelmisto kirjastot kuten Flyway ja Liquibase. Voitteko kuvitella pystyvänne vierittämään rakeisia muutoksia skeemaan kirjoittaessanne koodia? Liian usein, huomaan, että artikkeleita tietokannan muuttoliike ei keskustella siitä, mitä se tarkoittaa aktiivisesti tehdä yksi, kehittäjänä. Haluan korjata asian. Tämä mielessä, tänään annan sinulle kokonaiskuvan siitä, mitä tietokanta muuttoliike Sisältää ja miten se tehdään aktiivisessa kehitysympäristössä. Hajotan tämän kolmeen osaan, jotka kattavat mitä tapahtuu muuttoprosessin aikana, yhteiset työkalut, ja sudenkuopat, jotka voivat ilmaantua tietokannan muuttoliikkeen aikana. Tämän pitäisi antaa aloittelevalle kehittäjälle työkalut oppia nopeasti keskeiset ideat tiedonsiirron takana ja oppia myös mahdolliset sudenkuopat, joita vältetään, kun käytetään tietokantasiirtoa osana hänen kehitystyökalupakkiaan.
Mitä Tapahtuu Tietokantasiirron Aikana?
nyt kun tiedät, miten tietokantojen muuttoliikkeet syntyivät, anna kun selitän, mitä ne todellisuudessa sisältävät.
Rakemuutokset syntyvät yksittäisinä Skriptattuina tiedostoina
mainitsin, miten tietokannan migraatiot periaatteessa seuraavat rakemuutoksia tietokantarakenteeseesi (ja joskus myös tietoihisi). Nämä rakeiset muutokset näkyvät tyypillisesti erillisinä skriptattuina tiedostoina. Näin rakeinen skeemamuutokset näkyvät koodina, joka voidaan kaapata millä tahansa versionhallintaohjelmalla. Tämä on esimerkki siirtotiedoston Rails.
class CreateProducts < ActiveRecord::Migration def change create_table :products do |t| t.string :name t.text :description t.timestamps end endend
migraatioita voi olla paitsi itsenäisinä tiedostoina, myös nykyisellä tietokantarakenteella omana tiedostonaan. Tyypillisesti, tämä tunnetaan skeema tiedosto.
Tietokantasiirto skriptit ovat Työkaluriippuvaisia
muista Rubyn tietokantasiirto skripti aiemmasta esimerkistämme. Tässä on toinen tietokanta muuttoliike tiedosto riippumaton lähde control tietokantaohjelmisto 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>
tällä kertaa tiedosto on XML-muodossa. Itse asiassa Liquibase voi tuottaa migraatiomuutoksia (tai changesets, kuten he haluavat niitä kutsua) useissa muodoissa, kuten XML ja JSON. Joten ellet halua kirjoittaa tietokannan muuttoliike SQL-muodossa, ei ole olemassa todellisia standardeja koko miten muuttoliike tiedostot luodaan. Tietenkin, voit kirjoittaa oman mukautetun tietokannan muuttoliike skriptejä SQL-tiedostoja. Mutta miksi kirjoittaa käsin ja vahingossa ottaa käyttöön vikoja, kun voit käyttää työkaluja autogenate tietokannan muuttoliike?
miten teet tietokannan siirron?
nyt tiedät, mitä tietokantasiirto on. Sinun täytyy myös tietää (ainakin käsitteellisesti), miten suorittaa tietokannan siirto. Valitettavasti, ei ole standardeja ollenkaan tietokannan muuttoliike tiedostoja, mikä tarkoittaa, että emme voi päästä liian paljon yksityiskohtia siitä, miten luoda niitä. Toisin sanoen, miten suoritat tietokannan muuttoliike riippuu suuresti tietyn työkalun käytät tehtävään. Tässä osiossa, minä kattaa kaksi yleisintä tapaa suorittaa tietokannan muuttoliike.
vaihtoehto 1: Käytä viitekehystä/Kieliriippuvaista kirjastoa
, jos käytät kansankieltä (Ruby, PHP, Python jne.) tai puitteet (kiskot, Django jne.), sitten on olemassa hyvin dokumentoituja kirjastoja tiedonsiirrolle valitun kehyksen/kielen universumissa. Suosittu web kehykset luonnollisesti tulevat nipussa tietokannan muuttoliike ominaisuuksia. Asetuksista riippuen voit jopa vaihtaa natiivitietokannan siirron muihin kirjastoihin valitulla kielellä. Tyypillisesti tässä skenaariossa luot siirtotiedostot komentorivin avulla. Joskus, saatat joutua kirjoittamaan käsin mukautetun koodin joitakin muutoksia, kuten tietojen muuttoliike tai jopa miten kääntää muutos itse. Muuten, kirjasto valittu puitteissa / kieli melko paljon huolehtii tästä puolestasi.
Vaihtoehto 2: Käytä itsenäistä tietokanta-migraatioon keskittyvää ohjelmistoa
joissakin tapauksissa haluat käyttää flywayn tai Liquibasen kaltaisia ohjelmistoja, jotka toimivat vain tietokannan lähdeohjauksena. Näin et joudu lukkojen taa tiettyyn kehykseen tai kieleen. Tämä ei tarkoita, että sinulla on nolla lukitus. Otetaan esimerkiksi Flyway, joka toimii hyvin erilaisten tietokantojen kuten Oraclen, MySQL: n ja Mariadbin kanssa. Jos et käytä Flywayn Java-pohjaista muuttoliikettä (joka lukitsee sinut Javaan ja Flywayhin), saatat päätyä käyttämään SQL-pohjaista muuttoliikettä (joka lukitsee sinut valitsemaasi tietokantaan ja Flywayhin). Hyvä uutinen on Flyway ja Liquibase ovat molemmat suhteellisen helppokäyttöisiä. Nekin tarjoavat komentorivitavan migraatioiden luomiseen ja mahdollistavat mukautetun koodauksen tietokannan skeemamigraatioiden kaappaamiseen.
sinulle parhaan vaihtoehdon valitseminen
tässä oma mielipiteeni valinnasta jommankumman vaihtoehdon välillä. Olen yleensä nähdä useimmat kehittäjät valita vaihtoehto 1. Yleensä tämä johtuu siitä, että kehittäjillä on jo ensisijainen kieli/kehys, joten kognitiivisesti puhuen, se ei tunnu siltä, että he opettelevat (vielä) toista ohjelmistoa. Ja lukitus (jos vaihtoehto 1, tämä olisi puitteet ja kieli) on täysin vapaaehtoinen ja haluttu. Voit valita vaihtoehdon 2, jos tiimisi ei ole täysin sitoutunut tiettyyn kieleen tai viitekehykseen. Mihin tahansa menetkin, vältä muuttamasta valintaasi tarpeettomasti kehityksen puolivälissä. Tietokantasiirto ei ole alue, jossa työkalujen muuttaminen tuottaa sinulle valtavia etuja. Suurin osa eduista tulee yksinkertaisesti ottaa tietokanta muuttoliike perustettu ensimmäinen paikka.
Tietokantasiirtymän vaarat ja niiden välttäminen
edellisessä jaksossa I käsitteli kahta päätyyppiä tietokantasiirtymän työkaluja: framework/language-dependent and standalone software. Molemmat tyypit ovat helppokäyttöisiä. Nyt, suosittelen kolme parasta käytäntöä, kun se tulee todella suorittaa tietokannan muuttoliike. Nämä vinkit käsitellään suurin vaara tietokannan muuttoliike: haluat välttää peruuttamattomia muutoksia.
valitse yksi tietokannan siirtotyökalu ja pidä siitä kiinni
mainitsin tämän lyhyesti aiemmin, mutta kannattaa korostaa: haluan varoittaa tekemästä tarpeettomia muutoksia työkalusarjaan vain siksi, että se on siisti. Muista, että tietokannan muuttoliike skriptit ovat riippuvaisia työkalu käytät luoda niitä. Näille käsikirjoituksille ei ole kunnollisia standardeja. Jos todella haluat, voit jopa kirjoittaa oman SQL lausuntoja. Tämä esittelee oman joukko kysymyksiä; esimerkiksi, SQL skriptit ovat todennäköisesti voi olla tietokannasta riippuvainen. MySQL-kyselyt eivät välttämättä toimi PostgreSQL: ssä, ja päinvastoin. Joten joko olet lukittu tietokantaan muuttoliike työkalu, tai olet lukittu valitsemaasi tietokantaan-tai joissakin tapauksissa, jopa molemmat. Ei ole selvää hyötyä vaihtaa Työkalusetin usein, joten minun ehdotukseni on valita yksi tietokanta muuttoliike työkalu ja pysyä siinä. On parempaakin tekemistä kuin pyörittää pyörää turhaan.
poista rivit tai sarakkeet vain, kun olet aivan varma, että
on tarpeen, kun on kyse muuttoliikkeistä, voit useimmiten peruuttaa ne tarvittaessa. Tyypillinen tietokanta muuttoliike työkalut voivat käsitellä yksinkertaisia palautuvia muutoksia. Ja silloinkin, kun ne eivät voi, voit helposti lisätä oman mukautetun koodin auttaa peruuttaminen. Esimerkiksi Rails, voit yksinkertaisesti lisätä koodin alle käännettävä.
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
vaikeimmat muutokset peruuttamiseen liittyvät yleensä asioiden poistamiseen: erityisesti sarakkeiden tai datarivien poistamiseen. Jos tietokanta sisältää paljon tietoa, saatat päätyä tarvitse kirjoittaa huomattavan määrän mukautetun koodin yrittää kääntää muutoksia. Joten jos harkitset tietojen poistamista tietokannasta, ole erityisen varovainen. Tuollaisia muutoksia on vaikea perua. Muita vaikeasti käännettäviä muutoksia ovat sarakkeiden uudelleennimeäminen ja tiedon jo sisältävän sarakkeen datatyypin muuttaminen. Yksi nyrkkisääntö, jonka haluan mennä on tämä:sinun pitäisi lähes koskaan poistaa sarakkeita ennen seuraavaa suurta (et tiedä semver, eikö?) vapauttaa. Tämä sääntö pätee, vaikka minulla olisi sarakkeita, joiden käytön haluan lopettaa. Sen sijaan, että poistan sarakkeita, ilmoitan pienissä versioissa, mitkä sarakkeet vanhentuvat eteenpäin. Kun tulee suuren julkaisun aika, jätän ne kolumnit kokonaan pois. Siten vähennän mahdollisuuksia tehdä vahingossa, ei-toivottu muutos, joka on kauhea prosessi kääntää käsin.
toteuta Ominaisuusliput
toinen erinomainen strategia tietokantasiirtoon on ominaisuuslippujen toteuttaminen, varsinkin kun on iso tiimi ja useampi ihminen yrittää toteuttaa eri ominaisuuksia samaan koodibaasiin. Martin Fowlerin mukaan ominaisuusliput ovat ” tehokas tekniikka, jonka avulla joukkueet voivat muokata järjestelmän käyttäytymistä muuttamatta koodia.”Itse asiassa, isompi joukkue ja monimutkaisempi codebase on, sitä enemmän ominaisuus liput loistaa. Ominaisuusliput auttavat vähentämään riskiä, kun kyse on tietokantamuutoista. Yrittää selvittää muutoksia, kun sinun täytyy palauttaa tiettyjä ominaisuuksia voi olla todellinen painajainen. Ominaisuus liput toimivat yhtä hyvin, haluatko tehdä pieniä tai suuria tietokannan skeema muutoksia. Kun käytät ominaisuuslippuja, suosittelen, että pyrit yleisempiin ja rakeisempiin muutoksiin. Ja voit todella nähdä, miten ominaisuusliput auttavat kehitysprosessiasi, kun suoritat massiivisen kaavamuutoksen. Pyri silti rikkomaan tämä massiivinen kaavamuutos pienemmiksi, ohuiksi siivuiksi. Sinun ei tarvitse tehdä vaikutusta keneenkään sillä, kuinka paljon voit puristaa yhteen vaihtoon. Parempi lisätä suojatoimia oman kehityksen käytäntöjä toteuttamalla kaikki kolme suositusta olen puhunut tässä osiossa.
johtopäätös
kehittäjät tarvitsevat kaikki mahdolliset työkalut helpottaakseen elämäänsä. Tietokanta muuttoliike on yksi niistä must-have työkaluja kehittäjän työkalupakki. Tulevaisuudessa ennustan, että tietokantamuuttojen käyttäminen kehittyy kehityksen parhaasta käytännöstä kehityksen standardikäytännöksi. Ihmiset katsovat sinua hassusti, kun et käytä tietokantasiirtoa lainkaan. Silti, on tärkeää pitää mielessä, miten tietokanta migrations voi kostautua sinulle, erityisesti vaikeasti kääntää skeema muutoksia. Ole täysin varma näistä muutoksista, ennen kuin saat ne toimimaan. Jos et jo käytä tietokannan muuttoliike omassa prosessissa, mitä odotat? Se on helppo aloittaa, ja voit jopa lisätä sen puolivälissä oman kehityksen aikana. Tulet olemaan kiitollinen, että teit sen. Koska kun tulee päivä, että sinun täytyy rullata takaisin muutoksia ja muutokset liittyvät tietokantaan, toivot sinulla oli jotain auttaa sinua tekemään, että muutamassa sekunnissa. Tietokanta muuttoliike on, että jotain toivot sinulla olisi.