Kuidas versioonida andmebaasi?

Siiani olen mitmetes projektides saanud hakkama lihtsalt SQL konvert-skriptide kirjutamisega. Käsitsi ALTER TABEL-ite kirjutamine pole senini olulist peavalu valmistanud - küllap oleks kasuks ka mingi vahend nende lihtsamaks genereerimiseks aga mõningate keerukamate muudatuste puhul ei jää nagunii muud üle kui ise käsitsi skript kirjutada.

Seni päris lahendamata probleem on olnud, kuidas neid konvert-skripte hallata. Või kuidas neid üldse nimetada.

• Sai proovitud nimetamist SVN-i revisioni numbriga. Selgus, et mitte eriti hea mõte - ei soovitaks teistele. Lisaks ei kõlba see üldse kui tegemist hajutatud versioonihaldussüsteemiga.

• Tambeti välja pakutud kuupäevade kasutamine tundub seni parim nimetamisskeem, mis ma kuulnud olen. Kuigi mina eelistaks lisada väiksed eraldajad numbrite vahele AAAA-KK-PP, aga see on juba detailide küsimus.

• Kujutan ette veel varianti versiooninumbritega, aga need sinatsed kipuvad olema õite ebausaldusväärsed. Täna arendad 2.5.1 versiooni, aga homseks on saanud sellest juba 3.0 arendus.

Seejärel tuleb kirjutada miski skript, mis oskab vajalikud muudatused baasile rakendada. Oluline trikk siinkohal on tuvastamine, millise versiooniga andmebaasist tegemist on. Ju vast oleks hea kui selle versiooninumbri või kuupäeva saaks kuskilt failist või andmebaasist endast välja lugeda. Kus seda kõige parem hoida oleks, jään vastuse võlgu.

Railsi migreerimise osas on ehk ülevaatlikum see leht: http://guides.rubyonrails.org/migrations.html

Railsi migreerimise põhiline võlu seisneb selles, baasimuudatuse haldusühikuks on migratsioonifailid, millede rakendamise üle konkreetse baasiinstantsi vastu rails ise arvet peab. Sisuliselt "fire and forget" tüüpi lahendus, käsitsi haldamist praktiliselt ei ole.

Kasuta julgelt mõnda andmebaasi diffimise tarkvara. See võrdleb kahte andmebaasi ning kuvab nendevahelised erinevused (filtreerimisvalikud on laiad, mida võrrelda ja mida ignoreerida). Võrdluse pealt SQL skript (transaktsioon), mis transformeerib võrdlusest valitud erinevuste najal ühe baasi teisega üheseks. Arvesta muidugi sellega, et kui LIVE baasis on muudetavas tabelis juba näiteks 3.000.000 kirjet ning su skript muudab iga rida, siis admin võib heaga selle ööseks serverisse käima jätta.

Valik tööriistu konkreetselt selleks otstarbeks on lai, kuid (avaliku sektori suurimas IT asutuses) kasutame hetkel põhiliselt sellist töörista nagu Red Gate SQL Compare (http://www.red-gate.com/products/SQL_Compare/index.htm). Ühtegi viga ei ole kunagi täheldanud.

Vali mõni välja endale (trial peroodid peaks vist neil kõigil olema), katseta ning usu mind, sul ei tule pähegi enam kunagi et see võis kunagi probleem olla (mul tavaliselt läheb ca 10-15 minutit deploy paki koostamisel LIVEsse mineku eel andmebaasi skriptide koostamisele).

Soovitan uurida Liquibase võimalusi http://www.liquibase.org/ Siiamaani ei ole pidanud selles pettuma.

Üks variant on kirjutada konvertimine vastavasse programmi sisse ning hoida kuskil andmebaasis hetke tabelite versiooni.

Ning siis saad seda vastavalt soovile jooksutada.

Kui mingi veebirakendus, siis võib see konverter olla mingi osa veebirakendusest, mis uuendab tabelid. (näiteks iga kord kui uuendad midagi või muudad) Kui midagi muud, siis võib seda konverterit jooksutada programmi käivitamisel.

Mina tegin nii et andmebaasil on versiooninumber (mida hoitakse ühes konkreetses SystemParameter tabeli ühes väljas, ning koodis verifitseeritakse et andmebaasi versioon on sama), ning andmebaasiskriptid organiseeruvad kataloogidesse umbes sellise struktuuri järgi:

data/version-<N>/init/    // siin on skriptid millega vastava andmebaasiversiooni 
                          // saaks nullist ehitada
data/version-<N>/from-<M> // siin on versioonile <N> üleminekuskript versioonist <M>.

Skripte pidi küll käsitsi majandama aga kuna enamasti läks vaja ainult asju stiilis data/varsion-/from-, mis tekkisid kergelt ja peaaegu automaatselt siis polnud see väga raske.

Sellega saab sama hästi versioneerida mitte ainult schemat (ALTER TABLE) vaid ka teatud "baas andmed" (a-la mõned andmebaasis hoitavad Enum-id), muidu. Aga ega ma pole kindel et see kõige optimaalsem viis oleks.

Database Comparer (Boris Loboda) on hea. IBExperti sisse ehitatud vahend on ka hea. Mõned tüütud bugid sees aga ajab asja ära. IBExpertil on lisaks ka andmete võrdluse vahend. Tihtipeale läheb baase uuendades mõlemaid vaja.

Üldiselt on mul kaks baasi: tööbaas ja viimase reliisi baas Kui läheb uuendamiseks siis võrdlen reliisi baasi kliendi omaga. Tabelite modifikatsioonid tuleb ikka iga kord üle vaadata et miskit kaotsi ei läheks.

Lisaks olen kunagi teinud ka delphi versioonihaldus komponendi. Versioonid võivad olla string, number ja kuupäev. Komponent tuvastab baasi hetkeversiooni ja otsib sellele uuendus skripti (skript salvestatakse ressursidesse) ning käivitab selle. Kui komponendil on veel uuemaid skripte siis käivitatakse järgmine kuni jõutakse baasi viimase teadaoleva versioonini. Ühtlasi kontrollib ega baasil pole uuem versioon kui binaarile teada. Kui on siis genereerib vastava vea (a'la keegi tuli vana kliendiga baasi külge). Paraku sõltub devrace fibplus pakist mis on tasuline.