logi sisse meist KKK

Üsna normaalne on, et andmebaasist on mitu eksemplari:

  • Mitu installatsiooni mitme kliendi juures.
  • Eraldi arendusbaas, testbaas ja avalik baas.

Kui nüüd andmebaasis on muudatusi, siis tuleb need paigaldada ka kõikidesse teistesse eksemplaridesse. Mismoodi te olete selle lahendanud? Logite ALTER TABLE käsklusi? Kasutate mingit andmebaasiskeemide võrdlemise tööriistu? Jagage kogemusi!

Küsimus on inspireeritud Saiku Kaizen blogist.

küsitud Nov 03 '09 at 09:15

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77791125

edited Mar 10 '10 at 15:51

Rene%20Saarsoo's gravatar image

Rene Saarsoo ♦♦
1.1k101121


railsi migratsioonid on hea näide versioonimisest. IMHO elegantselt lahendatud.

Täpsemalt siin: http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

link

vastatud Nov 03 '09 at 14:53

anon's gravatar image

anon
231

edited Nov 04 '09 at 09:16

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77791125

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.

link

vastatud Nov 03 '09 at 21:25

Rene%20Saarsoo's gravatar image

Rene Saarsoo ♦♦
1.1k101121

Mul on hetkel üles pandud selline süsteem, et igaöiselt tehakse live baasist tagavarakoopia ning taastatakse testbaasi. Seejärel rakendatakse sellele testbaasile kõik konvert skriptid. Vigade logi tuleb meili peale. Seda kõike teeb üks bash skript. Nii saan mitu asja korraga - tagavarakoopia saab testitud + saan testida oma koodi live andmebaasiga. Selle tulemusena on release'i tegemine oluliselt pingevabamaks muutunud. Samuti kasutan seda testbaasi keerulisemate kasutajatoe probleemide lahendamisel - saan soperdada kliendi andmetega, ilma et see teda mõjutaks.

(Nov 04 '09 at 09:03) Tambet Matiisen ♦♦

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.

link

vastatud Jan 18 '10 at 16:19

AllarA's gravatar image

AllarA
511

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).

link

vastatud Mar 24 '10 at 21:50

Andres%20R.'s gravatar image

Andres R.
81114

Ise olen loginud SQL skeemi muutmise käsklused konvert skriptides. Mul on nad nimetatud kuupäevaliselt - konvert_AAAAKKPP.sql. Kuna mul on enamasti üks keskne andmebaas ja ainult arendus, test ja avalik baas, siis ma tavaliselt tean, mis kuupäeva versioon on avalikus baasis (üritan versioonikontrollis tagida kui muudatusi avalikustan) ja millised konvert skriptid tuleks rakendada. Vanad konvert skriptid tõstan eest ära arhiivi kataloogi.

Tegelikult ei kirjuta ma konvert skripte käsitsi, vaid genereerin Sybase PowerDesignerist. Selle eelis andmebaasiskeemide võrdlemise ees on see, et PowerDesigneri mudelis on rohkem infot, nt suudab ta tuvastada kas tabeli väli nimetati ümber või kustutati vana ja lisati uus. Töötab hästi, aga on tasuline (~8000 krooni SQL Anywhere koosseisus).

Olen kaalunud ka andmebaasiskeemide võrdlemist katsetada, sest kui see enam-vähem töötaks, saaks muudatused teha otse andmebaasis ja oleks arendus kiirem. Olen plaaninud katsetada DB Comparerit, aga pole aega leidnud.

link

vastatud Nov 03 '09 at 09:30

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77791125

Pisut põhjalikum analüüs koos erinevate lahendusvariantidega:

http://code.djangoproject.com/wiki/SchemaEvolution

Sisaldab ka palju viiteid edasisele lugemismaterjalile, vt sektsioone "Prior art" ja "Something Completely Different".

link

vastatud Nov 04 '09 at 09:22

Tambet%20Matiisen's gravatar image

Tambet Matiisen ♦♦
77791125

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

link

vastatud Jan 18 '10 at 12:43

RasmusP's gravatar image

RasmusP
2325

Ü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.

link

vastatud Nov 03 '09 at 10:22

egon's gravatar image

egon ♦♦
771239

Ma saan aru, et näiteks Ruby on Railsis ja Drupalis see nii ongi lahendatud. St konvert skriptid pead kirjutama käsitsi, aga sul on raamistik, mis neid skripte õigel hetkel rakendab.

(Nov 04 '09 at 09:15) Tambet Matiisen ♦♦

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.

link

vastatud Nov 10 '09 at 11:53

kt's gravatar image

kt ♦♦
112228

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.

link

vastatud Jan 16 '10 at 22:38

Pekk's gravatar image

Pekk
1

Sinu vastus
lülita eelvaade

Jälgi seda küsimust

By Email:

Pärast sisselogimist saad tellida muudatuse teavitusi siit

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *kaldkiri* või __kaldkiri__
  • **paks kiri** või __paks kiri__
  • link:[tekst](http://url.com/ "pealkiri")
  • pilt?![alt tekst](/path/img.jpg "pealkiri")
  • nummerdatud nimekiri: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • põhilised HTML märgendid on samuti toetatud

Pinu tööpakkumised

kõik pakkumised »

Küsimuse sildid:

×10
×3

küsitud: Nov 03 '09 at 09:15

nähtud: 3,756 korda

viimati uuendatud: Mar 24 '10 at 21:50

Litsents: Creative Commons Attribution License | Kontakt: info@pinu.ee