Zefirs Posted October 25, 2013 Report Share Posted October 25, 2013 Sveiki tautieši! Meklēju veidu, kā uzturēt datubāzi (Mysql) tik pat ērti, kā pirmkodu ar Git. Pēc pirmajiem meklējumiem sāku iepazīties ar http://off-scale.com/ un http://www.liquibase.org , varbūt varat padalīties ar savu pieredzi/risinājumiem? Quote Link to comment Share on other sites More sharing options...
F3llony Posted October 25, 2013 Report Share Posted October 25, 2013 Crude variants - dumpi un diff. Normālais variants - proxis starp db un klientu, kas reģistrē shēmas izmaiņas un veido drošas migrācijas ar datu rezerves kopēšanu. Sev pats rakstīju, jo analogu internetā neatradu. Šis un percona tools. Tādu offscale pirmo reizi dzirdu. Neuzticētu es tādam produkciju. Also, neuzticētu db instrumentiem kas paši kaut ko dara savā nodabā. Es pirms produkcijas vienmēr pārbaudu katras izmaiņas db lai nenodropētu vajadzīgus datus. Man drausmīgi kaitina pārsarežģītas lietas. Rakstīt kodā DB shēmu vai izmantot kaut kādu XML? Thanks, but no thanks. Iz pieredzes, bija mums te sistēma CMS kas salīdzināja db dumpus ar datubāzi un ieviesa shēmas izmaiņas (lasi - automātiskas migrācijas no shēmas dumpiem). Gadījās vienreiz noglabāts nedaudz vecāks dumps, kur lietotāju paroļu fieldi bija md5 char32. Produkcijā bija jau sen uzlikts crypt sha512. Attiecīgi ielādējot sistemu ar vecāku dumpu viss aizgāja pa pieskari un produkcijas paroles N tūkstošiem lietotāju tika nograizītas. Labi, ka pirms tam biju atcerējies uztaisīt backup un nobloķēt sistēmu lietotājiem. Quote Link to comment Share on other sites More sharing options...
l27 Posted October 25, 2013 Report Share Posted October 25, 2013 Versiju kontrolē veidoju direktoriju MySql, kur saglabāju SQL skriptu failus, ar kuriem tiek veiktas jebkādas db izmaiņas. Failu nosaukums: YYYYMMDD_[nosaukums].sql. Ja vienā reizē vairākas izmaiņas, taisu direktoriju, kurā numurēju sql failus pēc izpildes secības: 01_car_alter.sql, 02_invoice_add_index.sql. Vēl DB varētu izveidot tabulu, kurā automātiski reģistrējas izpildītie SQL skripti. Quote Link to comment Share on other sites More sharing options...
codez Posted October 25, 2013 Report Share Posted October 25, 2013 Manuprāt ļoti labs variants ir ģenerēt shēmas no konfigurāciju failiem vai modeļiem un pa tiešo db shēmām nepieķerties nekad. Tādā veidā versiju kontrolē būs šie faili, no kuriem jebkurā bridī var uzģenerēt pareizi db shēmu. Quote Link to comment Share on other sites More sharing options...
l27 Posted October 25, 2013 Report Share Posted October 25, 2013 Manuprāt ļoti labs variants ir ģenerēt shēmas no konfigurāciju failiem vai modeļiem un pa tiešo db shēmām nepieķerties nekad. Tādā veidā versiju kontrolē būs šie faili, no kuriem jebkurā bridī var uzģenerēt pareizi db shēmu. Kā ar migrāciju no versijas 1.1 uz 1.2? Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted October 25, 2013 Report Share Posted October 25, 2013 Ja pareizi saprotu, ka runa ir par db objektu instalāciju, klasifikatoru un konfigurācijas datiem, tad veidojot jaunu db: - db tabulas, indeksi, procedūras, jebkāds cits db objekts - create skripts - dati - insert skripti Taisot patchu: - db objekti - alter, drop, create - dati - update, delete, insert Manā iestādē mēs paralēli uzturam pilnu instalācijas komplektu, t.i., jebkurā brīdī var uztaisīt visu no jauna ar skriptiem, tai skaitā db objektus + sākotnējos kls un konfigurācijas datus. Kopš iepriekšējās versijas izmaiņas kā aprakstīts taisot patchu. Attiecīgi to visu var glabāt jebkurā versiju kontroles rīkā un salīdzināt, analizēt, ko nu katram vajag. Quote Link to comment Share on other sites More sharing options...
martins256 Posted October 25, 2013 Report Share Posted October 25, 2013 Pitona modulim sqlalchemy ir iebūvēta migrēšanas funkcija . Lūk arī piemēri, kā izskatās migrēšanas kods no vienas versijas uz citu. Datubāzes struktūra šajā gadījumā tiek definēta ar ORM. Quote Link to comment Share on other sites More sharing options...
Gints Plivna Posted October 25, 2013 Report Share Posted October 25, 2013 (edited) Kā ar migrāciju no versijas 1.1 uz 1.2? Atļaušos atbildēt. Ir vismaz 2 varianti: 1) Būt pietiekami disciplinētam un kodējot jebkurām shēmas izmaiņām uzreiz rakstīt ALTER skriptus, vai nu citu kas tur nepieciešams. 2) Ja tas kaut kādu iemeslu dēļ nav iespējams, tad var salīdzināt 2 shēmas un manuāli vai automātiski ģenerēt izmaiņu skriptu. Google iesitot compare schema mysql var dabūt optom variantus, sākot jau ar MySQL paša rīku mysqldbcompare. Protams, ka tas prasa uzturēt sākotnējo shēmu (piemēram, kā testa vidi), bet nu puslīdz normāla programmēšanas pieeja to prasa jebkurā gadījumā :) Edited October 25, 2013 by Gints Plivna Quote Link to comment Share on other sites More sharing options...
codez Posted October 25, 2013 Report Share Posted October 25, 2013 Kā ar migrāciju no versijas 1.1 uz 1.2? Visām "krutajām" ORM migrācijas sql ģenerēšana vai automātiska migrācija parasti ir iekšā. Quote Link to comment Share on other sites More sharing options...
Zefirs Posted October 25, 2013 Author Report Share Posted October 25, 2013 ORM netiek izmantots dēļ performance Quote Link to comment Share on other sites More sharing options...
gurkjis Posted October 25, 2013 Report Share Posted October 25, 2013 ORM netiek izmantots dēļ performance Un cik tad tu bieži raksti large scale applications ? ORMs ļoti palīdz samazinat izstrādes laiku. Ja aplikācija kļūst large scale (kas ne vienmēr notiek, pat ja klients uz to cer), ir iespēja to sākt optimizēt lielākajos bottleneck punktos. Quote Link to comment Share on other sites More sharing options...
codez Posted October 25, 2013 Report Share Posted October 25, 2013 (edited) Var jau neizmantot to orm, bet rakstīt tajā datubāzes tabulu struktūru un tālāk jau laist plikus kverijus. Edited October 25, 2013 by codez Quote Link to comment Share on other sites More sharing options...
daGrevis Posted October 25, 2013 Report Share Posted October 25, 2013 > ORM netiek izmantots dēļ performance Ha! Quote Link to comment Share on other sites More sharing options...
rpr Posted October 25, 2013 Report Share Posted October 25, 2013 Vai vari pamatot savu ironiju? Quote Link to comment Share on other sites More sharing options...
Zefirs Posted October 25, 2013 Author Report Share Posted October 25, 2013 Var jau neizmantot to orm, bet rakstīt tajā datubāzes tabulu struktūru un tālāk jau laist plikus kverijus. Jā par šo arī iedomājos. Tas darbojas, ja sistēma jāveido no 0, bet esošas sistēmas pārnest uz orm ir dažreiz neiespējami. Relācijas, atslēgu veidošana no foreign key utt., ir neiespējami realizēt uz dažādiem orm. Katram sava blusa ir. Bet tā risinājums ideāls attiecīgajos gadījumos. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.