[ vujkev @ 24.04.2009. 20:34 ] @
Na koji način vršite proveru strukture baze i eventualnu promenu iste.

Primera radi instaliramo neki program kod dva ili više klijenta. Posle xyz dana/godina napravimo novu verziju programa za koju je potreno promeniti strukturu baze (dodati neka polja u tabelu, promeniti neku SP i sl.). Klijent 1 uzme tu novu verziju dok svi ostali nastave da koriste staru. Opet posle xyz dana/godina naparvi se nova verzija sa novim izmenama na bazi, ali sad svi klijenti hoće da imaju novu verziju.

Moje pitanje je kako najlakse proveriti koju verziju baze ima koji klijent i kako promeniti istu tako da se kod klijenta "1" dodaju nova polja (SP, f-je . sl.) u odnosu na verziju 2, a da se kod ostalih klijenata dodaju novi objekti u odnosu na verzjiu 1.

Baza je neka RDBM (SQL, oracle, mysql i sl.), a ako je bitno program je rađen npr u .NET-u mada mene interesuje generalno rešenje.

[ jablan @ 24.04.2009. 20:43 ] @
http://guides.rubyonrails.org/migrations.html
[ vujkev @ 27.04.2009. 13:07 ] @
Koliko vidim ovo je usko vezano za ruby i ne objašnjava princip kako to generalno napraviti tako da mi ne pomaže previše. Neki drugi link?
[ mld @ 27.04.2009. 13:14 ] @
U literaturi se sreće i kao pojam "sinhronizacija strukture baza podataka".
[ djoka_l @ 27.04.2009. 13:31 ] @
Mi imamo u firmi alat koji zovemo dbdiff (interno razvijen), koji napravi fajl sa opisima DB objekata, zajedno sa sadržajima nekih šifarnika. Na ciljnoj mašini isti program uporedi fajl sa bazom i napravi SQL skriptove čijim se izvršavanjem baze dovedu na isto stanje.

Slični alati postoje, na primer u TOAD-u gde postoji slična mogućnost - ili da se dve on-line baze uporede ili da se izveze opis jedne baze u fajl, pa da se na drugoj mašini izvrši poređenje.

Naš pristup ne zahteva dodatni softver, a omogućava nam bolju kontrolu celog procesa.
[ jablan @ 27.04.2009. 15:20 ] @
Citat:
vujkev: Koliko vidim ovo je usko vezano za ruby i ne objašnjava princip kako to generalno napraviti tako da mi ne pomaže previše. Neki drugi link?

Pa rekao si da te interesuje generalno rešenje, mislim da je to u railsu jako elegantno urađeno, tako da možeš da pokupiš fazone odande, ili da tražiš neki sličan alat bliskiji tvojoj platformi...

Generalno, za svaki upgrade baze pišeš poseban fajl sa skriptama koje treba da se izvrše pri upgradeu i downgradeu i taj fajl numerišeš. U bazi držiš jednu tabelu u kojoj pamtiš poslednju verziju te baze. Pri migraciji samo proveravaš koje fajlove treba izvršiti na bazi i izvršavaš ih jedan po jedan.

SQLDiff i slični alati su više za jednokratne upotrebe, takav problem treba rešavati sistemski.