Mechanismy pro sledování změn schématu DB

hlasů
128

Jaké jsou nejlepší metody pro sledování a / nebo automatizaci změny DB schématu? Náš tým používá Subversion pro kontrolu verzí a my jsme byli schopni automatizovat některé z našich úkolů tímto způsobem (tlačit se hromadí na pracovní server, nasazení testovaný kód na produkční server), ale my jsme stále dělá aktualizace databáze ručně. Chtěl bych najít nebo vytvořit řešení, které nám umožní efektivně pracovat napříč servery s různými prostředími, zatímco nadále používat Subversion jako backend, jehož prostřednictvím jsou kód a DB aktualizace tlačil kolem různých serverech.

Mnoho populárních softwarových balíků zahrnují automatické aktualizace skripty, které detekují DB verzi a uplatňovat potřebné změny. Je to nejlepší způsob, jak to udělat, dokonce ve větším měřítku (mezi více projektů a někdy různých prostředích a jazycích)? Pokud ano, je tam nějaký stávající kód tam, že zjednodušuje proces nebo je to nejlepší jen valit naše vlastní řešení? Má někdo realizován něco podobného před a integrovat ji do Subversion post-commit háčky, nebo je to špatný nápad?

I když řešení, které podporuje více platforem by bylo vhodnější, budeme určitě potřebovat, aby podporovaly Linux / Apache / MySQL / PHP stack jako většina naší práce je na této platformě.

Položena 04/08/2008 v 22:31
zdroj uživatelem
V jiných jazycích...                            


20 odpovědí

hlasů
54

Ve světě Rails, je tu pojetí migrace, scénáře, ve kterých změny v databázi jsou v Ruby, spíše než chuť databáze je specifická pro SQL. Váš Ruby migrace kódu končí převáděna do DDL specifické pro váš aktuální databázi; toto dělá přepínání databázové platformy velmi snadné.

Za každé provedené změny do databáze, můžete psát novou migraci. Migrace mají typicky dvě metody: se „nahoru“ metoda, při které jsou použity změny a „dole“ způsobu, ve kterém jsou změny vrátit zpět. Jeden příkaz přináší databáze až do dnešního dne, a mohou být také použity, aby databáze pro konkrétní verzi schématu. V Rails, migrace jsou uloženy ve svém vlastním adresáři v adresáři projektu a dostat se zapsal do správy verzí, stejně jako jakýkoli jiný projekt kódu.

Tato příručka Oracle Rails migrace zahrnuje migraci docela dobře.

Vývojáři používající jiné jazyky se podíval na stěhování a zavedly své vlastní verze specifické pro jazyk. Znám Ruckusing , PHP migrací systému, který je po vzoru kolejích migrace; to by mohlo být to, co hledáte.

Odpovězeno 04/08/2008 v 23:45
zdroj uživatelem

hlasů
48

Používáme něco podobného bcwoord, aby naše databáze schémata synchronizovány přes 5 různých zařízení (produkce, fázování a několika instalacích vývoj), a zálohovány v řízení verzí, a to funguje docela dobře. Budu vypracovat trochu:


Chcete-li synchronizovat strukturu databáze, máme jednotný scénář, update.php a počet souborů očíslovaných 1.sql, 2.sql, 3.sql, atd. Skript používá jeden navíc tabulku uložit aktuální číslo verze databáze. Soubory N.sql jsou řemeslně ručně, jít od verze (N-1) na verzi N databáze.

Mohou být použity pro přidání tabulky, přidávat sloupce, migrovat data ze starého na nový formát sloupci přetažení sloupec, vložit „master“ řádky dat, jako jsou typy uživatelů, atd V zásadě to může dělat cokoliv, a s řádným daty migrační skripty už nikdy ke ztrátě dat.

Aktualizace skript funguje takto:

  • Připojení k databázi.
  • Vytvořit zálohu aktuální databáze (protože věci se pokazí) [mysqldump].
  • Vytvoření účetnictví tabulku (s názvem _meta), pokud neexistuje.
  • Přečíst aktuální verzi z _meta tabulky. Předpokládejme, 0, pokud nebyla nalezena.
  • Pro všechny .sql soubory očíslovány vyšší než verze, provést je v pořadí
  • Pokud jeden ze souborů produkoval chybu: vrátit zpět do zálohy
  • V opačném případě aktualizovat verzi v tabulce účetnictví na nejvyšší .sql souboru provedena.

Všechno jde do řízení zdrojů, a každá instalace má skript k aktualizaci na nejnovější verzi s jednou spuštění skriptu (volání update.php s vlastní databázi hesel apod). My Slov aktualizace scénu i produkční prostředí pomocí skriptu, který automaticky volá aktualizační skript databáze, takže kód aktualizace přichází s potřebnými aktualizací databáze.

Můžeme také použít stejný skript obnovit celou databázi od nuly; jsme jen kapka a znovu vytvořit databázi, spusťte skript, který bude zcela repopulate databázi. Můžeme také použít skript naplnit prázdnou databázi pro automatizované testování.


Trvalo jen několik hodin na zřízení tohoto systému je koncepčně jednoduché a každý dostane Systém číslování verzí, a to bylo neocenitelné v tom, že schopnost se pohybovat dopředu a vyvíjející se návrhu databáze, aniž by bylo nutné komunikaci nebo ručně provést změny na všech databází.

Dejte si pozor při vkládání dotazů od phpMyAdmin i když! Tyto generované dotazy obvykle obsahuje název databáze, kterou si určitě nechcete, protože to zlomí své skripty! Něco jako CREATE TABLE mydb. newtable(...) se nezdaří v případě, že databáze systému není volána mydb. Vytvořili jsme pre-komentář SVN háček, který znemožní .sql soubory obsahující mydbřetězec, což je jasné znamení, že někdo kopírovat / vložit z phpMyAdmin bez řádné kontroly.

Odpovězeno 22/08/2008 v 15:44
zdroj uživatelem

hlasů
11

Můj tým skripty všechny změny databáze a zavazuje tyto skripty SVN, spolu s každou verzí aplikace. To umožňuje postupné změny v databázi, aniž by došlo ke ztrátě dat.

Chcete-li přejít z jedné verze na další, stačí spustit soubor skriptů změnit, a vaše databáze je up-to-date, a pořád máš všechna svá data. To nemusí být nejjednodušší metoda, ale rozhodně to je efektivní.

Odpovězeno 05/08/2008 v 20:56
zdroj uživatelem

hlasů
9

Pokud jste stále hledají řešení: navrhujeme nástroj nazvaný neXtep designer. Jedná se o vývoj databázové prostředí, s nimiž si můžete dát celou svou databázi pod kontrolou verzí. Pracujete na verzi řízené úložišti, kde může být každá změna vysledovat.

Když je potřeba uvolnit aktualizace můžete dopustit svých komponent a produkt bude automaticky generovat upgrade SQL skript z předchozí verze. Samozřejmě, můžete generovat SQL ze všech 2 verzích.

Pak máte mnoho možností: můžete si vzít ty skripty a dát je do SVN pomocí kódu aplikace, takže to bude nasazen od vašeho stávajícího mechanismu. Další možností je použít mechanismus doručení neXtep: skripty jsou exportovány do takzvaný „doručování balíků“ (SQL skripty + XML deskriptoru) a instalační program může pochopit tento balíček a nasadit ji na cílový server a zároveň zajistit strcutural konzistence, závislost zkontrolujte, registrace instalovanou verzi, atd.

Výrobek je GPL a je založen na platformě Eclipse, takže to běží na systému Linux, Mac a Windows. To také podporuje Oracle, MySQL a PostgreSQL v současné době (podpora DB2 je na cestě). Podívejte se na wiki, kde najdete podrobnější informace: http://www.nextep-softwares.com/wiki

Odpovězeno 25/10/2010 v 06:46
zdroj uživatelem

hlasů
9

Tato otázka je zde opravdu usnadňuje vývojářům scénáře jejich vlastní lokální změny do ovládacího prvku zdroje sdílet s týmem. Já jsem stál před tento problém po mnoho let, a byl inspirován funkcí Visual Studio pro profesionály databáze. Pokud chcete, open-source nástroj se stejnými funkcemi, zkuste toto: http://dbsourcetools.codeplex.com/ Bavte - Nathana.

Odpovězeno 07/07/2009 v 14:26
zdroj uživatelem

hlasů
6

Scott Ambler produkuje velkou sérii článků (a spoluautorem knihy ) na databáze refaktorování s myšlenkou, že by měly v zásadě uplatňovat principy a postupy TDD k udržení schématu. Nastavíte řadu konstrukčních a sadby dat jednotkových testů pro databáze. Potom, než se nic nemění, upravit / psát testy, aby odrážel tuto změnu.

Byli jsme to dělat nějakou dobu nyní, a zdá se, že funguje. Napsali jsme kód pro generování základní název sloupce a datový typ kontroly v testovací jednotka sady. Můžeme znovu spustit tyto zkoušky kdykoli ověřit, že databáze v SVN pokladně odpovídá živé db aplikace je ve skutečnosti spuštěn.

Jak to dopadá, vývojáři někdy také vyladit jejich sandbox databázi a zanedbávat aktualizovat soubor schématu v SVN. Kód pak závisí na změně db, která nebyla zkontrolována. Taková chyba může být šíleně těžké nutit, ale testovací sada bude to vyzvednout ihned. To je zvláště hezké, kdyby jste ji postavit do většího Continuous plánu integrace.

Odpovězeno 29/08/2008 v 05:51
zdroj uživatelem

hlasů
6

Skládka schéma služby do souboru a přidat ho do ovládacího prvku zdroje. Pak jednoduchý diff vám ukáže, co se změnilo.

Odpovězeno 06/08/2008 v 17:59
zdroj uživatelem

hlasů
5

K. Scott Allen má slušnou článek nebo dva na schématu verzí, která využívá koncepci kumulativní aktualizaci scripts / migrace uvedenou v další odpovědi tady; viz http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx .

Odpovězeno 29/08/2008 v 06:11
zdroj uživatelem

hlasů
5

Pokud používáte C #, se podívat na podzvukovou, což je velmi užitečný nástroj ORM, ale také generuje SQL skript znovu si svůj scénář a \ nebo data. Tyto skripty pak může být uveden do ovládacího prvku zdroje.

http://subsonicproject.com/

Odpovězeno 04/08/2008 v 23:47
zdroj uživatelem

hlasů
5

Je to docela low-tech, a tam může být lepší řešení, tam venku, ale můžete prostě uložit schéma do SQL skriptu, který lze spustit vytvořit databázi. Myslím, že můžete provést příkaz k vytvoření tohoto skriptu, ale nemám bohužel znát příkaz.

Poté dopustit skript do ovládacího prvku zdroje spolu s kódem, který pracuje na tom. Když je nutné změnit schéma spolu s kódem, skript může být zkontrolována spolu s kódem, který vyžaduje změněné schéma. Poté bude diffs na scénář označují diffy na změny schématu.

U tohoto skriptu, můžete jej integrovat s DBUnit nebo jakési sestavení skriptu, takže se zdá, že by mohl zapadat do vašich již automatizovaných procesů.

Odpovězeno 04/08/2008 v 23:28
zdroj uživatelem

hlasů
4

Použil jsem následující strukturu databáze projektu v Visual Studio pro několik projektů, a to fungovalo docela dobře:

Databáze

změna skripty

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

vytvoření skriptů

sprocs

funkce

pohledy

Náš build systém poté aktualizuje databázi z jedné verze do druhé vykonáním skripty v následujícím pořadí:

1.PreDeploy.sql

2.SchemaChanges.sql

Obsah Vytvořit složku skripty

2.DataChanges.sql

3.Permissions.sql

Každý vývojář kontroly v jejich změn pro konkrétní chybu / vlastnost tím, že připojují svůj kód na konci každého souboru. Jakmile je hlavní verze je kompletní a rozvětvené v řízení zdrojů, obsahy .sql soubory ve složce Změna skripty jsou odstraněny.

Odpovězeno 08/08/2008 v 19:31
zdroj uživatelem

hlasů
4

Používáme velmi jednoduchý, ale přesto efektivní řešení.

U nových instalací, máme soubor metadata.sql v úložišti, která drží celý schématu DB, pak v procesu sestavení my tento soubor použít k vytvoření databáze.

Aktualizací, přidáme aktualizací v softwaru napevno. Držíme je napevno, protože nemáme rádi řešit problémy předtím, než to ve skutečnosti je problém, a takové věci neprokázala, že je problém tak daleko.

Takže v našem programu máme něco takového:

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

Tento kód zkontroluje, zda je databáze ve verzi 1 (která je uložena v tabulce vytvořené automaticky), pokud je zastaralý, pak příkaz je vykonán.

Chcete-li aktualizovat metadata.sql v úložišti, narazíme to upgraduje místně a poté extrahovat celý metadata databáze.

Jediná věc, která se děje každý tak často, je zapomenout spáchání metadata.sql, ale to není velký problém, protože jeho snadno testovat na proces vytváření a také jediná věc, která se může stát je, aby nová instalace s zastaralé databáze a modernizované ji při prvním použití.

Také nepodporujeme k degradaci, ale to je záměrné, pokud se něco rozbije na aktualizaci jsme obnovit předchozí verzi a opravit aktualizaci před dalším pokusem.

Odpovězeno 08/08/2008 v 19:21
zdroj uživatelem

hlasů
3

I vytvořit složky pojmenované po sestavení verze a dal upgrade a downgrade skripty tam. Například, mohli byste mít následující složky: 1.0.0, 1.0.1 a 1.0.2. Každý z nich obsahuje skript, který vám umožní upgrade nebo downgrade databáze mezi verzemi.

V případě, že klient nebo zákazník volat s problémem s verzí 1.0.1 a 1.0.2, který používáte, čímž databázi zpět do své verze nebude problém.

V databázi, vytvořit tabulku s názvem „schéma“, kam umístit v aktuální verzi databáze. Pak psát program, který dokáže změně verze databáze pro vás je snadné.

Stejně jako řekl Joey, pokud jste ve světě Rails pomocí migrace. :)

Odpovězeno 05/08/2008 v 05:36
zdroj uživatelem

hlasů
2

Zkuste db nasazovat - hlavně nástroj Java, ale pracuje s PHP stejně.

Odpovězeno 19/01/2012 v 02:52
zdroj uživatelem

hlasů
2

Líbí se mi způsob, jakým Yii zpracovává databáze migrace. Migrace je v podstatě PHP skript realizaci CDbMigration. CDbMigrationdefinuje upmetodu, která obsahuje logiku pro migraci. Je také možné implementovat downmetodu na podporu obrácení migrace. Alternativně, safeUpnebo safeDownmohou být použity, aby se ujistil, že migrace se provádí v rámci transakce.

Nástroj příkazového řádku Yii své yiicobsahuje podporu pro vytvoření a spuštění migrace. Migrace může být použita nebo obrácen, a to buď jednotlivě nebo v dávce. Vytvoření výsledky migrace v kódu pro třídu PHP provádí CDbMigration, jedinečně pojmenované založený na časové razítko a název migrace zadaný uživatelem. Všechny migrace, které byly předtím použity k databázi jsou uloženy v migrační tabulce.

Více informací naleznete v Database Migration článek z manuálu.

Odpovězeno 25/06/2011 v 14:18
zdroj uživatelem

hlasů
2

IMHO migrace mají obrovský problém:

Upgrade z jedné verze na druhou funguje dobře, ale dělat novou instalaci dané verze může trvat věčně, pokud máte stovky tabulek a dlouhou historii změn (jako my).

Běží celou historii delt od základního až do aktuální verze (pro stovky databází zákazníků) může trvat velmi dlouhou dobu.

Odpovězeno 12/03/2011 v 15:15
zdroj uživatelem

hlasů
2

Ropucha pro MySQL má funkci nazvanou schématu porovnat, který vám umožní synchronizovat 2 databází. Je to nejlepší nástroj, jsem dosud používají.

Odpovězeno 05/02/2011 v 12:08
zdroj uživatelem

hlasů
2

Doporučil bych používat Ant (Cross Platform) pro „skriptování“ straně (protože to může prakticky mluvit s jakýmkoliv db tam přes JDBC) a Subversion pro zdrojové úložiště. Ant bude hluboký, abyste „zálohovat“ svou db místních souborů před provedením změn. 1. záloha stávající db schema podat přes Ant 2. správu verzí pro Subversion přes Ant 3. posílat nové funkce SQL příkazy do DB přes Ant

Odpovězeno 17/09/2008 v 17:54
zdroj uživatelem

hlasů
2

Pro mé současné PHP projektu budeme používat myšlenku lišty migrací a máme adresář migrací, ve kterém jsme udržet soubory název „migration_XX.sql“, kde XX je počet migrací. V současné době jsou tyto soubory jsou vytvářeny ručně, jak jsou prováděny aktualizace, ale jejich tvorba může být snadno změněna.

Pak máme skript s názvem „Migration_watcher“, která, jak jsme v pre-alfa, v současné době běží na každém načtení stránky a kontroluje, zda je k dispozici nová migration_XX.sql soubor, kde XX je větší než aktuální migrační verze. Pokud tomu tak je, že běží všechny soubory migration_XX.sql až největším počtem proti databázi a voila! změny schématu jsou automatizovány.

Pokud požadujete schopnost vrátit se do systému by vyžadovalo hodně ladění, ale je to jednoduché a pracuje velmi dobře pro nás poměrně malý tým tak daleko.

Odpovězeno 23/08/2008 v 13:58
zdroj uživatelem

hlasů
0

K dispozici je příkazový řádek mysql-diff nástroj, který srovnává schémata databáze, kde schéma může být živá databáze nebo SQL skript na disku. Je to dobré pro většinu migrace schématu úlohy.

Odpovězeno 04/11/2009 v 20:43
zdroj uživatelem

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