Vă mulțumim pentru susținere

Există un sistem de control al versiunilor pentru modificările structurii bazei de date?

Deseori mă confrunt cu următoarea problemă.

Lucrez la unele modificări ale unui proiect care necesită noi tabele sau coloane în baza de date. Fac modificările bazei de date și continu să lucrez. De obicei, îmi amintesc să scriu modificările astfel încât să poată fi replicate pe sistemul live. Cu toate acestea, nu-mi amintesc mereu ce am schimbat și nu-mi amintesc mereu să-l scriu.

Deci, fac un impuls pentru sistemul live și a obține o eroare mare și evidentă că nu există NewColumnX , ugh.

Indiferent de faptul că aceasta nu este cea mai bună practică pentru această situație, există un sistem de control al versiunilor pentru bazele de date? Nu-mi pasă de tehnologia bazei de date specifice. Vreau doar să știu dacă există. Dacă se întâmplă să lucrați cu MS SQL Server, atunci minunat.

0
adăugat editat
adăugat autor Eric Haskins
Conform instrucțiunilor despre subiect , " Unele întrebări sunt încă în afara subiectului, chiar dacă se încadrează într-una din categoriile enumerate mai sus: ... Întrebările care ne cer să recomandăm sau să găsim o carte, un instrument, o bibliotecă de software, un tutorial sau o altă resursă în afara site-ului
adăugat autor Robert Columbia

19 răspunsuri

În Ruby on Rails, există un concept de migrare - un script rapid pentru a schimba Bază de date.

Generați un fișier de migrare, care are reguli pentru a mări versiunea db (cum ar fi adăugarea unei coloane) și reguli pentru a downgrada versiunea (cum ar fi eliminarea unei coloane). Fiecare migrare este numerotată, iar un tabel ține evidența versiunii curente db.

Pentru a emula migrați în sus , executați o comandă numită "db: migrate" care se uită la versiunea dvs. și aplică scripturile necesare. Puteți migra în jos în mod similar.

Scripturile de migrare în sine sunt păstrate într-un sistem de control al versiunilor - ori de câte ori schimbați baza de date verificați un script nou, și orice dezvoltator îl poate aplica pentru a aduce db-ul local la ultima versiune.

0
adăugat
Aceasta este alegerea pentru proiectele Ruby. Cea mai apropiată echivalentă cu acest design în java este migrarea schemelor mibatis. Pentru .NET echivalentul este code.google.com/p/migratordotnet . Toate acestea sunt instrumente excelente pentru acest post IMO.
adăugat autor Dan Tanner

Redgate are un produs numit Controlul Surselor SQL . Se integrează cu TFS, SVN, Vault SourceGear, Vault Pro, Mercurial, Perforce și Git.

0
adăugat

Pentru Oracle, folosesc Toad , care poate schimba o schemă într-un număr de fișiere discrete (de exemplu, un fișier per masa). Am câteva scripturi care gestionează această colecție în Perforce, dar cred că ar trebui să fie ușor de realizat în aproape orice sistem de control al revizuirii.

0
adăugat

Cele mai multe motoare de baze de date ar trebui să sprijine dumpingul bazei de date într-un fișier Știu că MySQL face, oricum. Acesta va fi doar un fișier text, astfel încât să puteți transmite acest lucru la Subversion sau orice altceva îl folosiți. Ar fi ușor să difuzați și pe fișiere.

0
adăugat
Da, dar difefiind fișierele SQL nu vă vor oferi scripturile necesare pentru a vă actualiza dev / prod db de la o revizuire la alta
adăugat autor Asaf Mesika

Există un cadru de migrare a bazei de date PHP5 numit Ruckusing. Nu am folosit-o, dar exemple arată ideea dacă utilizați limba pentru a crea baza de date ca și când este necesar, trebuie doar să urmăriți fișierele sursă.

0
adăugat

Aruncați o privire la pachetul oracol DBMS_METADATA.

În particular, următoarele metode sunt deosebit de utile:

  • DBMS_METADATA.GET_DDL
  • DBMS_METADATA.SET_TRANSFORM_PARAM
  • DBMS_METADATA.GET_GRANTED_DDL

Odată ce sunteți familiarizați cu modul în care funcționează (destul de explicativ), puteți scrie un script simplu pentru a arunca rezultatele acestor metode în fișiere text care pot fi puse sub controlul sursei. Mult noroc!

Nu sunt sigur dacă există ceva atât de simplu pentru MSSQL.

0
adăugat

Vă recomandăm foarte mult delta SQL . Eu doar folosesc-o pentru a genera scripturi diff atunci când am terminat de codificare caracteristica mea și a verifica aceste scripturi în instrumentul meu sursă de control (Mercurial :))

They have both an SQL server & Oracle version.

0
adăugat

PLSQL Developer, un instrument de la All Arround Automations, are un plugin pentru repositore care funcționează OK (dar nu minunat) cu Visual Source Safe.

From the web:

The Version Control Plug-In provides a tight integration between the PL/SQL Developer IDE >>and any Version Control System that supports the Microsoft SCC Interface Specification. >>This includes most popular Version Control Systems such as Microsoft Visual SourceSafe, >>Merant PVCS and MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

0
adăugat

Mă întreb că nimeni nu a menționat instrumentul open source liquibase bazat pe Java și ar trebui să funcționeze pentru aproape toate bazele de date care suportă jdbc. În comparație cu șinele folosește xml în loc de ruby ​​pentru a efectua modificările schemei. Deși nu-mi place xml pentru limbile specifice domeniului, avantajul foarte bun al xml este că lichibase știe cum să revină anumite operații ca

 
   

Deci nu trebuie să te ocupi de asta

Vor fi suportate și declarațiile pure SQL sau importurile de date.

0
adăugat
Pentru Java, recomandăm să consultați în zilele noastre flywaydb.org - a se vedea și compararea caracteristicilor de pe acest site
adăugat autor Karussell
folosim metodele de lichidare, dar folosim 3 abordari diferite pentru diferitele informatii: 1. structura (tabel, vizualizari, ...): istoricul schimbului 2. coduri (proceduri, pl / sql, functii): changelog cu un singur set de modificari marcat cu runalways = true runonchange = true 3. tabele de cod, alte meta "constante" stocate în tabele: aceeași abordare ca și pentru coduri, doar un set de modificări, ștergeți de la, introduceți toate informațiile
adăugat autor Palesz

Creați-vă inițial instrucțiuni de creare a tabelului în controlerul de versiuni, apoi adăugați instrucțiuni de modificare a tabelului, dar nu editați niciodată fișiere, doar modificați fișierele denumite în mod secvențial sau chiar ca un "set de modificări", astfel încât să puteți găsi toate modificările pentru o anumită implementare.

Cea mai dificilă parte pe care o pot vedea este urmărirea dependențelor, de exemplu pentru o anumită tabelă de implementare B ar putea fi necesară actualizarea înainte de tabelul A.

0
adăugat

Compararea schemelor pentru Oracle este un instrument special creat pentru a migra modificările de la baza noastră de date Oracle la alta. Vă rugăm să vizitați URL-ul de mai jos pentru link-ul de descărcare, unde veți putea utiliza software-ul pentru o încercare complet funcțională.

http://www.red-gate.com/Products/schema_compare_for_oracle/index. htm

0
adăugat

Sunt o școală veche, în care folosesc fișiere sursă pentru crearea bazei de date. Există de fapt 2 fișiere - project-database.sql și project-updates.sql - prima pentru schema și date persistente, iar cea de-a doua pentru modificări. Desigur, ambele sunt sub controlul sursei.

Când se modifică baza de date, mai întâi actualez schema principală în project-database.sql, apoi copiați informațiile relevante în project-updates.sql, de exemplu, instrucțiunile ALTER TABLE. Apoi pot aplica actualizările la baza de date de dezvoltare, testați, repetați până când se face bine. Apoi, verificați fișierele, încercați din nou și aplicați producției.

De asemenea, am de obicei un tabel în db - Config - cum ar fi:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Apoi, adaug următoarele la secțiunea de actualizare:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Codul db_version devine modificat numai când baza de date este recreată, iar db_revision îmi oferă o indicație cât de departe db este în afara liniei de bază.

I could keep the updates in their own separate files, but I chose to mash them all together and use cut&paste to extract relevant sections. A bit more housekeeping is in order, i.e., remove ':' from $Revision 1.1 $ to freeze them.

0
adăugat

Două recomandări de cărți: "Baze de date refactorizante" de Ambler și Sadalage și "Tehnici bazice de date agile" de Ambler.

Cineva a menționat Rails Migrations. Cred că funcționează excelent, chiar și în afara aplicațiilor Rails. Le-am folosit într-o aplicație ASP cu SQL Server pe care eram în curs de mutare în Rails. Verificați scripturile de migrare în VCS. Iată un post de Pragmatic Dave Thomas pe această temă.

0
adăugat

ER Studio allows you to reverse your database schema into the tool and you can then compare it to live databases.

Exemplu: Reveniți schema de dezvoltare în ER Studio - comparați-o cu producția și va lista toate diferențele. Poate să scaneze modificările sau să le împingă automat.

Odată ce aveți o schemă în ER Studio, puteți să salvați scenariul de creație sau să îl salvați ca binar proprietate și să îl salvați în controlul versiunii. Dacă doriți vreodată să vă întoarceți la o versiune anterioară a schemei, verificați-o și împingeți-o pe platforma dvs. db.

0
adăugat

Îmi scriu scripturile de lansare db în paralel cu codarea și păstrez scripturile de lansare într-o secțiune specifică proiectului din SS. Dacă fac o schimbare a codului care necesită o modificare db, atunci actualizez scriptul de lansare în același timp. Înainte de lansare, rulez scriptul de lansare pe un dev dev db (structurat copiat de la producție) și fac testele mele finale pe el.

0
adăugat

În absența unui VCS pentru schimbarea tabelului, le-am înregistrat într-un wiki. Cel puțin atunci văd când și de ce a fost schimbat. Este departe de a fi perfect, deoarece nu toată lumea o face și avem mai multe versiuni de produse în uz, dar mai bine decât nimic.

0
adăugat

Dacă utilizați SQL Server, ar fi greu să bateți Data Dude (aka ediția de baze de date a Visual Studio). Odată ce obțineți atârnă de ea, a face o comparație schemă între versiunea dvs. sursă controlată a bazei de date și versiunea în producție este o briza. Și cu un clic puteți genera DDL diff.

Există un video pe MSDN care este foarte util.

Știu despre DBMS_METADATA și Toad, dar dacă cineva ar putea să vină cu un Data Dude pentru Oracle, atunci viața ar fi foarte dulce.

0
adăugat

Am folosit MS Team System Database Edition cu destul de bun succes. Se integrează cu controlul versiunilor TFS și Visual Studio mai mult sau mai puțin fără probleme și ne permite să gestionăm cu ușurință procs, vizualizări etc. Rezolvarea conflictelor poate fi o durere, dar istoria versiunii este completă odată ce se termină. Ulterior, migrațiile către AQ și producție sunt extrem de simple.

Este corect să spunem că este vorba despre un produs de versiunea 1.0, însă nu este fără câteva probleme.

0
adăugat

MyBatis (formerly iBatis) has a schema migration, tool for use on the command line. It is written in java though can be used with any project.

Pentru a realiza o bună practică de gestionare a schimbărilor bazelor de date, trebuie să identificăm câteva obiective-cheie.   Astfel, MyBatis Schema Migration System (sau MyBatis Migrations pentru scurt) caută să:

  • Lucrați cu orice bază de date nouă sau existentă
  • Folosiți sistemul de control al sursei (de exemplu, Subversion)
  • Activați dezvoltatorii sau echipele concurente să lucreze independent
  • Permite conflictele foarte vizibile și ușor de gestionat
  • Permite migrarea înainte și înapoi (evoluează, devine respectiv)
  • Faceți starea curentă a bazei de date ușor accesibilă și ușor de înțeles
  • Activați migrațiile, în ciuda privilegiilor de acces sau a birocrației
  • Lucrați cu orice metodologie
  • Încurajează practici bune, coerente
0
adăugat