2

Nov

Modernne tarkvara loomine III: Andmebaasi versioonimine

Marek Tihkan 7 kommentaari

Koodi versioonime on küllaltki elementaarne nähtus (jah, mõned tõesti ei tee seda, kuid selles situatsioonis ei taha väga ükski meeskond olla), kuid andmebaas on jäänud tihti tahaplaanile. Esimesi praktikaid on hoida meeskonnas ühte jagatud andmebaasi. See võib alguses hea mõttena tunduda, kuid kahjuks pole versioonimisest haisugi ja meeskond näeb erinevaid jõukatsumusi selle haldamisel.

Selleks, et versioonida andmebaasi peame selle mingil moel koodihoidlasse saama. Teame, et SQL skripte annab küllaltki lihtsalt teha ning võiksime teha kolm faili: Create, Data ja Destroy. Nüüd tuleb need lihtsalt käivitada enda lokaalses masinas ja ongi andmebaas arendamiseks olemas ja versioonihalduses. Lahendus töötab küllaltki hästi, kui meil on paar tabelit ainult.

Uurisin mingi hetk Ruby on Railsi, et vaadata sealseid innovaatilisemaid ideid ning seal on lahendatud andmebaasi haldamine muudatuste (migration) kaudu. Luuakse fail muudatuse kohta, mis koosneb kahest osast: muudatuste lisamine (up) ja muudatuste eemaldamine (down); versiooni suurendamine ja versiooni vähendamine. Kuna 100 muudatuse puhul muutub tülikaks ja ajanõudvaks uut baasi luua, siis on võimalik ka terve andmebaasi skript luua (schema dump).

.NET maailmas on ka samalaadsed töövahendid loodud: Tarantino, Migrator.NET, RikMigrations, MachineMigrations ja SubSonic Migrations. Valik on päris kirju.

Siiski on veel alternatiive: võime kasutada ka Visual Studio Database projekti, mille abil saame korda saata nii mõndagi. See minu teada ei luba muudatusi teha, kuid hoiab tervet andmebaasi struktuuri kontrolli all ning loob vastava muudatuste skripti andmebaasi järgi (Schema compare). Lisaks võimaldab ka testandmeid genereerida. Igati väärt alternatiiv.

Ja nüüd jutt ka laisematele inimestele ning keda oluliselt ei huvita, milline see andmebaas välja näeb. Enamik ORM-e suudavad luua andmebaasi põhjal olemeid (Entity) ja ka olemitest andmebaase. Seega tuleks buildi käigus mõni ORM-i funktsioon käivitada. Ehtne näide on NHibernate-i näol olemas.

Hea, et jõudsite selle läbi lugeda ja nüüd võin eeldada, et teil pole enam väga mõjuvaid põhjusi andmebaasi versioonimata jätta. Java ja PHP taustaga inimesed võiksid kommenteerida, mida nad kasutavad andmebaaside haldamisel. Mul see teadmine praegu kahjuks puudub.

Loe veel sarnastel teemadel:

  • Share/Bookmark

KATEGOORIAD » Arendus

SILDID » , , ,

7 kommentaari

1

Hei. Tõepoolest:

“Java ja PHP taustaga inimesed võiksid kommenteerida, mida nad kasutavad andmebaaside haldamisel.”

Ootaks vastuseid huviga.

Küll aga võiks ehk analoogseid küsimusepüstitusi teha ka meie oma stackoverflows: http://www.pinu.ee ?

Jüri
18:57, 2. november

2

Ma arvan, et PHP puhul on see haldus raamistikupõhine, enamikus ilmselt puudub. Mõned, nagu näiteks Doctrine on saanud inspiratsioonid Railsi Migrationitest – http://www.doctrine-project.org/documentation/manual/1_1/en/migrations

Priidik Vaikla
22:48, 2. november

4

deploy puhul on hea see, et enamus deploy keskkondi sobib suvalise softi deploymiseks. seega esmased lahendused capistrano, vladi näol versioonitava tarkvara liigutamiseks on kasutatavad sõltumatult platvormist

aga konkreetselt php teemal:

http://phing.info/trac/
http://www.davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy/
http://carouth.com/2009/10/20/the-modern-php-workflow/

tervete andmebaaside liigutamiseks võib kasutada shellikaid või teha capistanosse eraldi taskid

Anton
21:57, 3. november

5

Tänan Anton väärt viidete eest. Muidugi Capistrano, CruiseControl jms ei aita hoida andmebaasi ennast versioonituna, vaid aitavad kogu rakendust deploy’da.

Marek Tihkan
14:22, 4. november

6

On olemas veel selline vahva asi nagu AXMLS (http://phplens.com/lens/adodb/docs-datadict.htm). Sellel on küll mitmeid puudujääke ja keerulisemate andmebaasistruktuuride puhul ilmselt ei ole rakendatav, kuid idee on iseenesest väga huvitav ja kui keegi seda natuke edasi arendaks / alternatiivse asja looks, oleks see üks mugavamaid viise andmebaasi versioonimiseks.

Raido
17:35, 4. november

7

kui googlist php jaoks spetsiaalselt otsida leiab tegelikult sarnaseid vidinaid päris palju, küsimus on mida sa viitsid ja pead vajalikuks enda jaoks või ettevõtte jaoks juurutada, sest juurutamine võtab kõige rohkem auru tegemaks asju nii, et tiimis ka teised sellest mida sa teed mingit kasu saaksid.

Minu arvates oleks hea, kui schema upgrade ja downgrade käiks rakenduse kaudu, st, et rakendus teaks mis versiooniga schemat ta parasjagu vajab ja oskaks ise upgradeda , kui vaja. Andmete migreerimine ühest kohast teise või clustrite vahel võiks jääda üldiste deploy/migreerimisvahendite hooleks

Anton
22:12, 4. november

Lisa kommentaar

  • * Kuvatakse kommentaari juures
  • * Ei publitseerita