Mecanisme de modificare schemă de urmărire DB

voturi
128

Care sunt cele mai bune metode de urmărire și / sau automatizarea modificărilor DB schemă? Echipa noastră folosește Subversion pentru versiunea de control si am fost capabili de a automatiza unele dintre sarcinile noastre în acest fel (împingând construiește până la un server de așteptare, implementarea codului testat pe un server de producție), dar vom face încă actualizări de baze de date manual. Aș dori să găsească sau să creeze o soluție care ne permite să lucreze eficient pe mai multe servere cu diferite medii în timp ce continuă să folosească Subversion ca backend prin care actualizări de cod și DB sunt împinse în jurul valorii de la diferite servere.

Multe pachete software populare includ auto-actualizare script-uri care detectează versiunea DB și aplica modificările necesare. Este cel mai bun mod de a face acest lucru chiar și pe o scară mai mare (în mai multe proiecte și medii, uneori, mai multe și limbi)? Dacă da, există vreun cod existent acolo, care simplifică procesul sau este cel mai bine să se rostogolească doar propria noastră soluție? Are cineva ceva similar puse în aplicare înainte și integrat în Subversion post-comite cârlige, sau este o idee rea?

În timp ce o soluție care suportă mai multe platforme, ar fi de preferat, cu siguranta avem nevoie pentru a sprijini Linux / Apache / MySQL / PHP stiva ca cea mai mare parte a muncii noastre este pe această platformă.

Întrebat 04/08/2008 la 22:31
sursa de către utilizator
În alte limbi...                            


20 răspunsuri

voturi
54

În lumea Rails, există conceptul de migrare, script-uri în care se schimbă în baza de date sunt realizate în Ruby, mai degrabă decât o aromă-bază de date specifică SQL. Codul dvs. de migrare Ruby sfârșește prin a fi convertite în specificul DDL la baza de date curentă; acest lucru face trecerea de platforme de baze de date foarte usor.

Pentru fiecare modificare efectuată la baza de date, scrieți o nouă migrație. Migrații au de obicei două metode: o „up“, metodă în care sunt aplicate modificările și o metodă „în jos“, în care modificările sunt anulate. O singură comandă aduce baza de date la zi, și pot fi de asemenea folosite pentru a aduce baza de date într-o anumită versiune a schemei. In Rails, migrații sunt păstrate în propria lor director în directorul de proiect și se verifică în versiunea de control la fel ca orice alt cod de proiect.

Acest ghid Oracle pentru Rails migrări acoperă migrații destul de bine.

Dezvoltatorii care folosesc alte limbi au uitat la migrări și au pus în aplicare propriile versiuni specifice fiecărei limbi. Știu de Ruckusing , un sistem de migrare PHP , care este modelat dupa migratii Rails'; ar putea fi ceea ce căutați.

Publicat 04/08/2008 la 23:45
sursa de către utilizator

voturi
48

Noi folosim ceva similar cu bcwoord pentru a păstra noastre baze de date sincronizate schemele pe 5 instalații diferite (de producție, de așteptare și câteva instalații de dezvoltare), și susținute în controlul versiunilor, și funcționează destul de bine. O să elaboreze un pic:


Pentru a sincroniza structura bazei de date, avem un singur scenariu, update.php, și un număr de dosare numerotate 1.sql, 2.sql, 3.sql, etc Script-ul foloseste un tabel suplimentar pentru a stoca curent numărul versiunii Bază de date. Fișierele N.sql sunt lucrate manual, pentru a trece de la versiunea (N-1) la versiunea N a bazei de date.

Ele pot fi folosite pentru a adăuga tabele, adăugați coloane, migrați date dintr-un vechi într-un nou format de coloană, apoi picătură coloana, introduceți „master“ de rânduri de date, cum ar fi tipurile de utilizatori, etc. Practic, se poate face orice, și cu datele corespunzătoare script-urile de migrare nu veți pierde date.

Script-ul de actualizare funcționează astfel:

  • Conectarea la baza de date.
  • Faceți o copie de rezervă a bazei de date curente ( pentru că lucrurile vor merge prost) [mysqldump].
  • Creați tabelul de contabilitate (numit _meta), în cazul în care nu există.
  • Citește versiunea curentă din tabelul _meta. Să presupunem 0 dacă nu a fost găsit.
  • Pentru toate fișierele .sql numerotate mai mare decât versiunea, să le execute în ordine
  • Dacă unul dintre fișierele produs o eroare: rostogolească înapoi la rezervă
  • În caz contrar, actualizați versiunea în tabelul de contabilitate la cel mai înalt fișierul .sql executat.

Totul merge în sursă de control, și fiecare instalație are un script pentru a actualiza la cea mai recentă versiune cu o execuție unic de script (de asteptare update.php cu buna baza de date cu parole etc.). Noi SVN actualizare de așteptare și medii de producție prin intermediul unui script care apelează automat script-ul de actualizare a bazei de date, astfel încât o modificare de cod vine cu actualizările bazei de date necesare.

Putem folosi, de asemenea, același script pentru a recrea întreaga bază de date de la zero; am doar picătură și recreați baza de date, apoi executați script-ul care va repopula complet baza de date. Putem folosi, de asemenea, script-ul pentru a popula o bază de date goală pentru testare automată.


A fost nevoie de doar câteva ore pentru a configura acest sistem, este conceptual simplu și toată lumea devine schema de numerotare a versiunilor, și a fost de neprețuit în a avea capacitatea de a merge mai departe și în evoluție proiectarea bazei de date, fără a fi nevoie de a comunica sau de a executa modificările manual pe toate bazele de date.

Feriți - vă când inserați interogări de la phpMyAdmin , deși! Aceste interogări generate includ de obicei, numele bazei de date, care cu siguranță nu doriți , deoarece va rupe scripturile! Ceva de genul CREATE TABLE mydb. newtable(...) va eșua în cazul în care baza de date privind sistemul nu este numit mydb. Am creat un cârlig de pre-SVN comentariu care va interzice .sql fișierele care conțin mydbșirul, care este un semn sigur că cineva copie / lipit de phpMyAdmin fără verificare corespunzătoare.

Publicat 22/08/2008 la 15:44
sursa de către utilizator

voturi
11

Scripturile mele echipa din toate modificările de baze de date, și se angajează aceste script-uri pentru a SVN, împreună cu fiecare lansare a aplicației. Acest lucru permite modificări incrementale ale bazei de date, fără a pierde date.

Pentru a trece de la o versiune la alta, trebuie doar pentru a rula set de script-uri de schimbare, iar baza de date este de până la zi, și încă mai ai toate datele. Este posibil să nu fie cea mai simplă metodă, dar cu siguranta este eficient.

Publicat 05/08/2008 la 20:56
sursa de către utilizator

voturi
9

Dacă sunteți încă în căutarea de soluții: ne propunem un instrument numit neXtep designer. Este un mediu de dezvoltare de baze de date cu care vă puteți pune întreaga bază de date de sub control al versiunii. Lucrezi pe un depozit în cazul în care fiecare versiune controlată de schimbare poate fi urmărită.

Când aveți nevoie pentru a elibera o actualizare, vă puteți angaja componentele și produsul va genera automat script-ul de actualizare SQL din versiunea anterioară. Desigur, puteți genera acest SQL de la oricare 2 versiuni.

Apoi, aveți mai multe opțiuni: puteți lua aceste script-uri și le-a pus în SVN cu codul aplicației, astfel încât acesta va fi implementat de către mecanismul existent. O altă opțiune este de a utiliza mecanismul de livrare a neXtep: script-uri sunt exportate în ceva numit un „pachet de livrare“ (script-uri SQL + descriptor XML), și un program de instalare poate înțelege acest pachet și să implementați un server țintă asigurând în același timp coerența strcutural, dependența verifica, înregistrarea versiune instalată, etc.

Produsul este GPL și se bazează pe Eclipse , astfel ruleaza pe Linux, Mac și Windows. De asemenea, susține Oracle, MySQL și Postgresql în acest moment (suport DB2 este pe drum). Atunci o privire la wiki unde veți găsi informații mai detaliate: http://www.nextep-softwares.com/wiki

Publicat 25/10/2010 la 06:46
sursa de către utilizator

voturi
9

Problema aici este de a face într - adevăr mai ușor pentru dezvoltatorii de la script - ul propriile lor modificări locale în sursă de control pentru a partaja cu echipa. M - am confruntat cu această problemă de mai mulți ani, și a fost inspirat de funcționalitatea Visual Studio pentru profesioniști baze de date. Dacă doriți un instrument open-source cu aceleași caracteristici, încercați acest lucru: http://dbsourcetools.codeplex.com/ Have fun, - Nathan.

Publicat 07/07/2009 la 14:26
sursa de către utilizator

voturi
6

Scott Ambler produce o mare serie de articole (și co-autor la o carte ) pe refactoring bază de date, cu ideea că ar trebui să se aplice în mod esențial principiile și practicile TDD pentru a menține schema. Ați creat o serie de structură și de semințe de teste unitare de date pentru baza de date. Apoi, înainte de a schimba ceva, modifica / scrie teste pentru a reflecta această schimbare.

Am făcut acest lucru pentru o perioada de timp acum și se pare să funcționeze. Am scris cod pentru a genera numele coloanei de bază și dataType controale într-o suită de unitate de testare. Putem oricând executați din nou acele teste pentru a verifica dacă baza de date în casă SVN se potrivește live db aplicația este, de fapt rulează.

După cum se dovedește, de asemenea, dezvoltatorii tweak, uneori, baza lor de date Sandbox și neglijează să actualizeze fișierul schema în SVN. Codul depinde apoi de o schimbare db care nu a fost verificat. Acest fel de bug-ul poate fi înnebunitor greu de stabilit, dar suita de test se va ridica imediat. Acest lucru este deosebit de frumos dacă ai construit-o într-un plan continuu de integrare mai mare.

Publicat 29/08/2008 la 05:51
sursa de către utilizator

voturi
6

Dump schema într-un fișier și adăugați-l la controlul sursei. Apoi, un simplu dif vă va arăta ceea ce sa schimbat.

Publicat 06/08/2008 la 17:59
sursa de către utilizator

voturi
5

K. Scott Allen are un articol decent sau două pe versionare schemă, care utilizează conceptul de script - uri de actualizare elementare / migrații se face referire în alte răspunsuri de aici; vezi http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Publicat 29/08/2008 la 06:11
sursa de către utilizator

voturi
5

Dacă utilizați C #, au o privire la subsonic, un instrument ORM foarte util, dar, de asemenea, generează script sql pentru a recreat schema si \ sau date. Aceste script-uri pot fi apoi puse în sursă de control.

http://subsonicproject.com/

Publicat 04/08/2008 la 23:47
sursa de către utilizator

voturi
5

E cam scăzut tech, și ar putea fi o soluție mai bună acolo, dar ai putea stoca doar schema într-un script SQL care poate fi rulat pentru a crea baza de date. Cred că se poate executa o comandă pentru a genera acest scenariu, dar eu nu știu comanda, din păcate.

Apoi, comite script-ul în sursă de control, împreună cu codul care funcționează pe ea. Când trebuie să modificați schema împreună cu codul, script-ul poate fi verificată în împreună cu codul care necesită modificat schema. Apoi, diff pe script-ul va indica diff pe modificările de schemă.

Cu acest scenariu, ai putea integra cu DBUnit sau un fel de scenariu construi, asa se pare s-ar putea potrivi cu procesele deja automatizate.

Publicat 04/08/2008 la 23:28
sursa de către utilizator

voturi
4

Am folosit următoarea structură a proiectului de baze de date în Visual Studio pentru mai multe proiecte și a funcționat destul de bine:

Bază de date

Schimbarea Scripturi

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Creați Scripturi

Sprocs

funcţii

Vizualizări

Sistemul nostru construi actualizează apoi baza de date de la o versiune la alta prin executarea script-urile în următoarea ordine:

1.PreDeploy.sql

2.SchemaChanges.sql

Conținutul Creare dosar Scripturi

2.DataChanges.sql

3.Permissions.sql

Fiecare dezvoltator verifică în modificările lor pentru un anumit bug / facilitate prin alăturarea lor cod pe la sfârșitul fiecărui fișier. Imediat ce o versiune majoră este completă și ramificată în controlul sursei, conținutul fișierelor .sql din folderul Modificare Scripts sunt șterse.

Publicat 08/08/2008 la 19:31
sursa de către utilizator

voturi
4

Noi folosim o soluție foarte simplă, dar încă eficientă.

Pentru noi instalări, avem un fișier metadata.sql în depozit, care deține toate schema DB, apoi, în procesul de construire vom folosi acest fișier pentru a genera baza de date.

Pentru actualizări, vom adăuga actualizări în software-ul hardcoded. Noi păstrați-l hardcoded pentru că nu ne place rezolvarea problemelor înainte de a fi într-adevăr o problemă, și acest tip de lucru nu sa dovedit a fi o problemă până acum.

Deci, în software-ul nostru avem ceva de genul:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Acest cod va verifica dacă baza de date este în versiunea 1 (care este stocată într-un tabel creat automat), în cazul în care este depășit, atunci comanda este executată.

Pentru a actualiza metadata.sql în magazia, vom rula acest upgrade-uri la nivel local și apoi extrage metadatele completă a bazei de date.

Singurul lucru care se întâmplă în fiecare atât de des, este de a uita săvârșirea metadata.sql, dar acest lucru nu este o problemă majoră, deoarece ușor de a testa pe procesul de construire și, de asemenea, singurul lucru care se poate întâmpla este de a face o instalare nouă, cu o bază de date învechite și actualizat la prima utilizare.

De asemenea, nu acceptăm scăderile, dar este prin design, dacă ceva se rupe pe o actualizare, am restaurat versiunea anterioară și repara actualizarea înainte de a încerca din nou.

Publicat 08/08/2008 la 19:21
sursa de către utilizator

voturi
3

Am crea foldere denumite după versiunile construi și a pus actualizarea și downgrade script-uri acolo. De exemplu, ați putea avea următoarele dosare: 1.0.0, 1.0.1 și 1.0.2. Fiecare conține script-ul care vă permite să faceți upgrade sau downgrade baza de date între versiuni.

În cazul în care un client sau un client suna cu o problemă cu versiunea 1.0.1 și utilizați 1.0.2, aducând baza de date înapoi la versiunea lui nu va fi o problemă.

În baza de date, a crea un tabel numit „schemă“ în cazul în care ați pus în versiunea curentă a bazei de date. Apoi scrie un program care poate face upgrade sau downgrade baza de date pentru tine este ușor.

La fel ca Joey a spus, dacă sunteți într-o lume Rails, utilizați migrații. :)

Publicat 05/08/2008 la 05:36
sursa de către utilizator

voturi
2

Încercați db-deploy - în principal, un instrument de Java, dar funcționează cu PHP, de asemenea.

Publicat 19/01/2012 la 02:52
sursa de către utilizator

voturi
2

Îmi place modul în care Yii se ocupă de migrări de baze de date. O migrare este de fapt un script PHP de punere în aplicare CDbMigration. CDbMigrationdefinește o upmetodă care conține logica de migrare. De asemenea , este posibil să se pună în aplicare o downmetodă de a sprijini inversarea migrației. În mod alternativ, safeUpsau safeDownpot fi folosite pentru a se asigura că migrarea se face în cadrul unei tranzacții.

Instrument de linie de comandă Yii lui yiicconține sprijin pentru a crea și executa migrații. Migrații poate fi aplicată sau inversată, fie unul câte unul sau într - un lot. Crearea unui rezultat de migrare în cod pentru o clasă PHP de punere în aplicare CDbMigration, numit în mod unic pe baza unui marcaj de timp și un nume de migrare specificată de către utilizator. Toate migrații care au fost aplicate anterior la baza de date sunt stocate într - un tabel de migrare.

Pentru mai multe informații , consultați baza de date de migrare articolul din manualul.

Publicat 25/06/2011 la 14:18
sursa de către utilizator

voturi
2

migrări IMHO nu au o problemă uriașă:

Actualizarea de la o versiune la alta lucrări fine, dar faci o instalare proaspătă de o versiune dată ar putea dura pentru totdeauna, dacă aveți sute de tabele și o istorie lungă de modificări (cum facem noi).

Rularea întreaga istorie a delte, deoarece valoarea inițială de până la versiunea curentă (pentru sute de baze de date ale clienților) s-ar putea dura foarte mult timp.

Publicat 12/03/2011 la 15:15
sursa de către utilizator

voturi
2

Toad pentru MySQL are o functie numita schemă de comparare care vă permite să sincronizați 2 baze de date. Acesta este cel mai bun instrument am folosit până acum.

Publicat 05/02/2011 la 12:08
sursa de către utilizator

voturi
2

Mi-ar recomanda utilizarea Ant (cross-platform) pentru partea „Scripting“ (deoarece poate vorbi practic la orice db acolo prin JDBC) și Subversion pentru depozitul de sursă. Ant va alow să „copie de rezervă“ db-ul la fișierele locale, înainte de a face modificări. 1. copie de siguranță schema db existente la dosar prin intermediul Ant 2. control al versiunii pentru Subversion depozitul prin Ant 3. trimite noi declarații SQL pentru a db prin intermediul Ant

Publicat 17/09/2008 la 17:54
sursa de către utilizator

voturi
2

Pentru proiectul meu PHP, folosim ideea de sine migrări și avem un director migrații în care vom păstra fișierele din titlu „migration_XX.sql“ unde XX este numărul migrației. În prezent, aceste fișiere sunt create de mână, ca actualizările sunt făcute, dar crearea lor ar putea fi modificate cu ușurință.

Apoi, avem un scenariu numit „Migration_watcher“, care, așa cum suntem în pre-alfa, în prezent se execută pe fiecare pagina de încărcare și verifică dacă există un nou fișier migration_XX.sql unde XX este mai mare decât versiunea curentă de migrare. Dacă da, ruleaza toate fișierele migration_XX.sql până la cel mai mare număr de baza de date și voila! modificări de schemă sunt automatizate.

Dacă aveți nevoie de capacitatea de a reveni sistemul ar necesita o mulțime de tweaking, dar este simplu și a fost de lucru foarte bine pentru echipa noastră destul de mici până acum.

Publicat 23/08/2008 la 13:58
sursa de către utilizator

voturi
0

Există o linie de comandă mysql-dif instrument care compară scheme de baze de date, în cazul în care schema poate fi o bază de date în direct sau script - ul SQL pe disc. Este bine pentru cele mai multe sarcini de migrare schemă.

Publicat 04/11/2009 la 20:43
sursa de către utilizator

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more