Mechanizmusok nyomkövető DB sémamódosításokat

szavazat
128

Melyek a legjobb módszer a követés és / vagy automatizálásával DB sémamódosításokat? Csapatunk használja Subversion verziókezelő és képesek voltunk, hogy automatizálják néhány feladatok ilyen módon (tolás épít fel egy átmeneti szerver telepítése tesztelt kódot egy éles szerveren), de mi még mindig csinál adatbázis frissítések kézzel. Szeretném megtalálni, vagy hozzon létre egy megoldás, amely lehetővé teszi számunkra, hogy hatékonyan működik a szerverek különböző környezetekben, miközben továbbra is használni Subversion backend-ként, amelyen keresztül kód és a DB frissítések nyomni körül a különböző szerverek.

Sok népszerű szoftvercsomag közé tartozik az automatikus frissítés script, amely érzékeli a DB változat, és alkalmazza a szükséges változtatásokat. Ez a legjobb módja annak, hogy ezt még nagyobb léptékű (több projekt között, és néha több környezetet és nyelvek)? Ha igen, van-e a meglévő kódot, hogy ott leegyszerűsíti a folyamatot, vagy ez a legjobb, csak hogy forgassa a saját megoldás? Van valaki végre valami hasonló előtt, és beépítette Subversion utáni elkövetni horgok, vagy ez egy rossz ötlet?

Bár a megoldás, amely támogatja a több platformon előnyösebb lenne, akkor feltétlenül szükség van, hogy támogassa a Linux / Apache / MySQL / PHP verem, mint a legtöbb munkánk ezen a platformon.

A kérdést 04/08/2008 22:31
a forrás felhasználó
Más nyelveken...                            


20 válasz

szavazat
54

A Rails világban, ott van a koncepció vándorlások, scriptek, amely megváltoztatja az adatbázisba készülnek Ruby helyett adatbázis-specifikus ízét SQL. A Ruby költöztetőkódjában végül is átalakíthatjuk a DDL jellemző a jelenlegi adatbázis; ez teszi kapcsolási adatbázis platform nagyon egyszerű.

Minden változás csinál az adatbázishoz, akkor írj egy új migráció. Migrációk általában két módszer: „up” módszer, amelyben a változás alkalmazzák, és a „lefelé” módszer, amelyben a változtatás elveszik. Egyetlen parancs hozza az adatbázis naprakész, és is fel lehet használni, hogy az adatbázis egy adott változata a sémát. A Rails vándorlások tartják a saját könyvtárába a projekt könyvtárát és leellenőrzi a verzió ellenőrzés, mint bármely más projekt kódot.

Ez az Oracle bemutatása Rails migrációk borító migrációk elég jól.

Azok a fejlesztők más nyelveken is nézett a migráció és hajtották végre a saját nyelv-specifikus változatok. Ismerek Ruckusing , a PHP migrációk rendszer mintájára Rails migrációk; lehet, hogy mit keres.

Válaszolt 04/08/2008 23:45
a forrás felhasználó

szavazat
48

Mi használ valami hasonló bcwoord tartani adatbázisunkban sémák szinkronizáltan 5 különböző berendezések (termelés, staging és néhány fejlesztési létesítmények), és figyelemmel kísérik a verziókövetés, és ez elég jól működik. Majd kidolgozza egy kicsit:


Szinkronizálni az adatbázis szerkezete, van egy script, update.php, és számos fájlt számozott 1.sql, 2.sql, 3.sql stb A szkript egy extra táblázatban tárolja az aktuális verziószámát adatbázisban. A N.sql fájlok ügyes kézzel, hogy menjen a verzió (N-1) verzióra N az adatbázisban.

Ezeket fel lehet használni hozzá asztalok, add oszlopok, vándorolnak az adatokat egy régi egy új oszlop formátumban, majd dobja az oszlop, helyezze a „mester” adatsort, mint a felhasználói típusok, stb Alapvetően, akkor semmit, és a megfelelő adatokat migrációs szkriptek sose veszítsd el az adatokat.

A frissítés script működik, mint ez:

  • Csatlakozni az adatbázishoz.
  • Készítsen biztonsági másolatot a jelenlegi adatbázis (mert dolog lesz baj) [mysqldump].
  • Készítsen könyvelés asztal (ún _meta), ha nem létezik.
  • Olvasd el a jelenlegi verziót _meta asztalra. Tegyük fel, hogy 0, ha nem található.
  • Minden .sql fájlok számozott magasabb verzió, végrehajtja azokat annak érdekében,
  • Ha az egyik file-okat egy hiba: visszaállíthatja a biztonsági másolatot
  • Ellenkező esetben frissíti a verziót a könyvelési táblázat legmagasabb .sql fájl végrehajtásra.

Minden megy a forrás ellenőrzés, és minden telepítés egy script, hogy frissítse a legújabb verzióra egyetlen szkript végrehajtása (hívó update.php a megfelelő adatbázis jelszó, stb.) Mi svn update staging és a termelési környezet segítségével egy script, ami automatikusan meghívja az adatbázis frissítést, így a kód frissítés érkezik a szükséges adatbázis-frissítések.

Azt is használja ugyanazt a forgatókönyvet, hogy újra a teljes adatbázist az alapoktól; mi csak csepp és újra az adatbázist, majd futtatni a szkriptet, ami teljesen elszaporodni az adatbázist. Mi is használjuk a forgatókönyvet feltölteni egy üres adatbázist automatizált tesztelés.


Beletelt csak néhány órát, hogy hozzanak létre ezt a rendszert, ez fogalmilag egyszerű és mindenki megkapja a verzió számozási sémát, és felbecsülhetetlen értékű volt, amely képes haladni, és fejlődik az adatbázis tervezés, anélkül, hogy kommunikálni, vagy manuálisan végre a módosításokat minden adatbázisokat.

Vigyázni kell, mert ha beillesztés lekérdezések phpMyAdmin mégis! Azok generált lekérdezések általában tartalmazzák az adatbázis nevét, amit biztosan nem akar, mert megtöri a szkripteket! Olyasmi, mint a CREATE TABLE mydb. newtable(...) sikertelen lesz, ha az adatbázist a rendszer nem hívják mydb. Létrehoztunk egy előre megjegyzést SVN horog, amely megtiltja .sql fájlokat tartalmazó mydbszöveg, ami biztos jele annak, hogy valaki a másolás / beillesztés a következőtől phpMyAdmin nem megfelelő ellenőrzése.

Válaszolt 22/08/2008 15:44
a forrás felhasználó

szavazat
11

A csapatom script az összes adatbázis változásait, és kötelezi azokat szkriptek SVN együtt minden kiadása a kérelmet. Ez lehetővé teszi a fokozatos változások az adatbázis, adatvesztés nélkül.

Amennyiben az egyik kiadás a következő, akkor csak meg kell futtatni a készlet változás szkripteket és az adatbázis up-to-date, és még mindig van az összes adatot. Lehet, hogy nem a legegyszerűbb módszer, de ez biztosan hatásos.

Válaszolt 05/08/2008 20:56
a forrás felhasználó

szavazat
9

Ha még mindig keresi a megoldásokat: teszünk javaslatot nevű eszköz neXtep tervezők. Ez egy adatbázis-fejlesztési környezet, amellyel meg lehet tenni az egész adatbázis alapján verzió ellenőrzése. Ha a munka egy változata ellenőrzött gyűjtemény, ahol minden változás nyomon követhető.

Ha szükség van, hogy kiadja egy frissítést, akkor lehet elkövetni az összetevők és a terméket automatikusan generál SQL frissítés script az előző változathoz képest. Persze, akkor létrehoz ezt az SQL bármely 2 változatban.

Akkor sok közül: lehet, hogy ezeket a szkripteket, és tedd meg SVN az alkalmazás kódját úgy, hogy lesz által alkalmazott meglévő mechanizmus. Egy másik lehetőség az, hogy a szállítási mechanizmusa neXtep: scriptek exportált egy úgynevezett „csomagnak” (SQL szkriptek + XML leíró) és egy telepítő megérti ezt a csomagot, és telepítse azt a cél kiszolgáló biztosítása mellett strcutural következetesség, függőség ellenőrizze, regisztráció telepített verzió stb

A termék GPL és alapul Eclipse így fut Linux, Mac és Windows. Azt is támogatja az Oracle, MySQL és PostgreSQL pillanatában (DB2 támogatás az úton). Akkor nézd meg a wiki, ahol talál részletes információkat: http://www.nextep-softwares.com/wiki

Válaszolt 25/10/2010 06:46
a forrás felhasználó

szavazat
9

A kérdés itt valóban így könnyen a fejlesztők számára, hogy script saját helyi változásokat forrás vezérlés megosztani a csapat. Már szembe ezzel a problémával sok éven át, és ihlette a funkcionalitást a Visual Studio adatbázis szakemberek. Ha Ön is szeretne egy nyílt forrású eszköz az azonos funkciók, próbáld ki ezt: http://dbsourcetools.codeplex.com/ Jó szórakozást, - Nathan.

Válaszolt 07/07/2009 14:26
a forrás felhasználó

szavazat
6

Scott Ambler termel nagy cikksorozatot (és társszerzője a könyv ) az adatbázis újraírás, azzal a gondolattal, hogy meg kell alapvetően alkalmazni TDD elvek és gyakorlat fenntartása a sémát. Ön létrehozott egy sor szerkezeti és vetőmag adatok egység vizsgálatok az adatbázisba. Aztán, mielőtt bármit is módosítana, módosít / ír vizsgálatok, hogy tükrözze ezt a változást.

Tettük ezt egy darabig, és most úgy tűnik, működik. Írtunk kódot generál az alap oszlop nevét és az adattípus ellenőrzéseket egy egység tesztelése suite. Mi lehet ismételni ezeket a vizsgálatokat bármikor ellenőrizheti, hogy az adatbázis az SVN checkout megegyezik az élő db a futó alkalmazások valójában.

Mint kiderül, a fejlesztők néha csípés a sandbox adatbázis és elhanyagolása frissíteni a sémafájl SVN. A kód ezután függ db változás, hogy nem ellenőrizték a. Ez a fajta hiba lehet őrjítően nehéz pin le, de a tesztsorozat majd vedd fel rögtön. Ez különösen szép, ha már épített egy nagyobb Continuous Integration tervet.

Válaszolt 29/08/2008 05:51
a forrás felhasználó

szavazat
6

Dump a séma egy fájlt, és add meg a forrás ellenőrzése. Ezután egy egyszerű diff megmutatja, hogy mi változott.

Válaszolt 06/08/2008 17:59
a forrás felhasználó

szavazat
5

K. Scott Allen egy tisztességes cikket vagy két séma verziószámozást, amely az inkrementális frissítés scripts / migrációk koncepció hivatkozott más válaszokat itt; lásd http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Válaszolt 29/08/2008 06:11
a forrás felhasználó

szavazat
5

Ha a C #, vessen egy pillantást a szubszonikus, egy nagyon hasznos ORM eszköz, hanem az is generál sql script, hogy újra a rendszert, és \ vagy adat. Ezek a szkriptek azután helyezték forrás ellenőrzés.

http://subsonicproject.com/

Válaszolt 04/08/2008 23:47
a forrás felhasználó

szavazat
5

Ez kicsit low-tech, és ott lehet a jobb megoldás ott, de akkor is csak tárolja a séma egy SQL script amely lehet futtatni az adatbázis létrehozása. Azt hiszem, akkor végre a parancsot, hogy létrehoz a szkript, de nem tudom, a parancs sajnos.

Ezután elkövetni a scriptet forrás ellenőrzése mellett, hogy a kód működik rajta. Ha meg kell változtatni a séma mellett a kódot, a szkript lehet ellenőrizni együtt a kódot, amely előírja, hogy a megváltozott sémát. Ezután diffs a script jelzi diffs a sémamódosításokat.

Ezzel a script, akkor azt integrálja DBUnit vagy valamilyen szkriptet, így úgy tűnik, hogy beleillik a már automatizált folyamatokat.

Válaszolt 04/08/2008 23:28
a forrás felhasználó

szavazat
4

Már használt a következő adatbázis projekt felépítése Visual Studio több projekt, és ez nagyon jól működött:

adatbázis

Változás Scripts

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Készítsen Scripts

Sprocs

Funkciók

Nézetek

A build rendszer frissíti az adatbázist egy változata a következő végrehajtó a script az alábbi sorrendben:

1.PreDeploy.sql

2.SchemaChanges.sql

Tartalma létrehozása Scripts mappában

2.DataChanges.sql

3.Permissions.sql

Minden fejlesztő ellenőrzéseket saját változik egy adott hiba / funkció appending a kód-ra a végén minden fájlt. Ha egy nagyobb változat teljes és elágazó forrás kontroll, a tartalmát a .sql fájlok módosítása Scripts mappában kell hagyni.

Válaszolt 08/08/2008 19:31
a forrás felhasználó

szavazat
4

Mi egy nagyon egyszerű, de mégis hatékony megoldás.

Az új telepítések, van egy metadata.sql fájlt az adattárban amely rendelkezik az összes DB séma, majd a fordítási folyamat is használják ezt a fájlt generálni adatbázisba.

Frissebb, adjuk hozzá a frissítéseket a szoftver bedrótoztak. Mi tartja kódolt, mert nem tetszik problémák megoldására, mielőtt valóban egy probléma, és ez a fajta dolog nem bizonyítja, hogy egy probléma eddig.

Így a szoftver van valami, mint ez:

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

Ez a kód ellenőrzi, hogy az adatbázis verzió 1 (amely tárolja a létrehozott táblázat automatikusan), ha ez elavult, akkor a parancs végrehajtásra kerül.

Ha frissíteni a metadata.sql a tárolóban, mi fut ez frissíti a helyi, majd vonjuk ki a teljes adatbázis metaadatokat.

Az egyetlen dolog, ami történik minden olyan gyakran, hogy felejtsük el a elhatározod metadata.sql, de ez nem olyan nagy probléma, mert a könnyű tesztelni a fordítási folyamat és az egyetlen dolog, ami történhet, hogy egy új telepíthető egy elavult adatbázisok és korszerűsített ez az első használatkor.

Szintén nem támogatjuk merül, de ez a design, ha valami elromlik egy frissítés, helyreállítottuk a korábbi verziót, és rögzítse a frissítés mielőtt újra próbálkozna.

Válaszolt 08/08/2008 19:21
a forrás felhasználó

szavazat
3

Hozok létre mappát elnevezett építmények változat, és tegye frissíteni, és leértékeli scriptek ott. Például, akkor a következő mappákat: 1.0.0, 1.0.1 és 1.0.2. Mindegyik tartalmazza a script, amely lehetővé teszi, hogy magasabb vagy alacsonyabb az adatbázis verziók között.

Ha az ügyfél vagy az ügyfél hívni a probléma verzió 1.0.1 és 1.0.2 használ, így az adatbázis vissza a verzió nem lesz probléma.

Az adatbázisban, hozzon létre egy táblázatot az úgynevezett „séma”, ahová a jelenlegi változata az adatbázis. Aztán írt egy programot, amely magasabb vagy alacsonyabb szintű adatbázis az Ön számára egyszerű.

Csakúgy, mint Joey azt mondta, ha egy Rails világ használja Migrations. :)

Válaszolt 05/08/2008 05:36
a forrás felhasználó

szavazat
2

Próbálja db telepíthető - elsősorban a Java eszköz, de működik a PHP is.

Válaszolt 19/01/2012 02:52
a forrás felhasználó

szavazat
2

Szeretem a módját, hogyan Yii kezeli adatbázis migráció. A migráció alapvetően egy PHP script végrehajtása CDbMigration. CDbMigrationmeghatároz egy upmódszer, amely tartalmazza a migráció logikát. Arra is lehetőség van, hogy végre egy downmódszer, hogy támogassa megfordítása a migráció. Alternatív safeUpvagy safeDownlehet használni, hogy győződjön meg arról, hogy az átállás történik keretében a tranzakciót.

Yii parancssoros eszköz yiictartalmaz támogatást, hogy hozzon létre, és végre vándorlás. Bevándorlás lehet alkalmazni, vagy fordítva, akár egyenként, akár szakaszosan. Létrehozása a migráció eredményez kód PHP osztály végrehajtási CDbMigration, egyedileg megnevezett alapuló időbélyeg és a migrációs neve a felhasználó által megadott. Minden migrációk, amelyek korábban már alkalmazott az adatbázisban tárolt migráció táblázatban.

További információkért lásd a Database Migration cikket az utasítás.

Válaszolt 25/06/2011 14:18
a forrás felhasználó

szavazat
2

IMHO migrációk van egy óriási probléma:

Frissítés egyik verzió egy másik jól működik, de ezzel egy friss telepítés egy adott változata lehet, hogy örökre, ha van száz táblázatok és hosszú története változások (mint mi).

Futás az egész története delták, mivel a kiindulási akár a jelenlegi verzió (több száz ügyfél adatbázisok) eltarthat egy nagyon hosszú idő.

Válaszolt 12/03/2011 15:15
a forrás felhasználó

szavazat
2

Toad for MySQL függvényét séma össze, amely lehetővé teszi, hogy szinkronizálja 2 adatbázisok. Ez a legjobb eszköz, amit eddig használt.

Válaszolt 05/02/2011 12:08
a forrás felhasználó

szavazat
2

Azt javasoljuk Ant (cross platform) a „script” oldalán (hiszen gyakorlatilag beszélni bármilyen db ott JDBC-n keresztül), és a Subversion a repository. Ant alow, hogy „biztonsági másolatot” a db a helyi fájlok, a módosítások elvégzése előtt. 1. tartalék meglévő db séma fájlba keresztül Ant 2. verzióképzési Subversion keresztül Ant 3. küldeni az új SQL utasításokat a DB-n keresztül Ant

Válaszolt 17/09/2008 17:54
a forrás felhasználó

szavazat
2

Mert a jelenlegi PHP projekt használjuk az ötlet sínek migráció és van egy migrációk könyvtárat, amelyben tartjuk fájlok neve „migration_XX.sql”, ahol XX a száma az elvándorlást. Jelenleg ezek a fájlok által létrehozott kézzel frissítések készülnek, hanem azok is könnyen módosítható.

Aztán van egy script úgynevezett „Migration_watcher”, amely, mint mi vagyunk pre-alpha, jelenleg fut minden oldalon terhelés és ellenőrzi, hogy van egy új migration_XX.sql fájl ahol XX nagyobb, mint a jelenlegi migrációs változat. Ha így halad minden migration_XX.sql fájlokat akár a legnagyobb számban az adatbázison, és íme! sémamódosításainak automatizált.

Ha szüksége van arra, hogy visszatérjen a rendszer igényel sok csípés, de ez egyszerű, és már nagyon jól működik a mi meglehetősen kis csapat eddig.

Válaszolt 23/08/2008 13:58
a forrás felhasználó

szavazat
0

Van egy parancssori mysql-diff eszköz, amely összehasonlítja adatbázissémákat adott séma lehet egy élő adatbázis vagy az SQL script a lemezen. Ez jót tesz a legtöbb sémakonvertálási feladatokat.

Válaszolt 04/11/2009 20:43
a forrás felhasználó

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