Versioning SQL Server adatbázis

szavazat
288

Azt akarom, hogy az én adatbázisok alapján verzió ellenőrzése. Van valakinek bármilyen tanácsot vagy ajánlott cikkek érts kezdődött?

Majd azt szeretné, hogy legalább néhány adat van (mint alumb említi: felhasználói típusok és adminisztrátorok számára). Én is gyakran szeretnének egy nagy gyűjtemény a keletkezett vizsgálati adatok mérést tesz lehetővé.

A kérdést 01/08/2008 19:33
a forrás felhasználó
Más nyelveken...                            


29 válasz

szavazat
38

Ez az egyik a „kemény problémák” környező fejlődését. Amennyire én tudom, nincs tökéletes megoldás.

Ha csak akkor kell tárolni az adatbázis struktúrát, és nem az adatok akkor export az adatbázis SQL lekérdezések. (Enterprise Manager: Jobb klikk a adatbázis -> Generate SQL script. Azt ajánljuk, hogy a „create egy fájlt tárgy” az opciók fül) Ezután elkövetni ezeket a szöveges fájlokat svn és használja svn a diff és naplózási funkciókat.

Én ezt összekötve egy Batch script, hogy vesz egy pár paramétert, és beállítja az adatbázist. Azt is hozzá néhány további lekérdezéseket adja alapértelmezett adatokat, mint a felhasználói típusok és az admin felhasználó. (Ha több információt szeretnél erről, tegye valamit, és tudom rakni a forgatókönyvet valahol hozzáférhető)

Ha meg kell tartani az összes adat is, én javasoljuk, hogy egy biztonsági másolatot az adatbázis és használata Redgate ( http://www.red-gate.com/ ) termékeket tenni az összehasonlításokat. Nem olcsó mulatság, de ők minden pénzt megér.

Válaszolt 01/08/2008 20:28
a forrás felhasználó

szavazat
169

Martin Fowler írt kedvenc cikket a témában, http://martinfowler.com/articles/evodb.html . Nem szeretnék tenni séma guba alatt változat ellenőrzés alumb és mások szerint azért, mert szeretnék egy egyszerű módja annak, hogy frissíteni a termelési adatbázisba.

Egy webes alkalmazás, ahol lesz egy egységes termelési adatbázis például, azt használja a két technika:

Adatbázis Frissítés Scripts

A szekvencia adatbázis aktualizáló szkriptek, amelyek tartalmazzák a DDL kell mozgatni a séma verzióról N az N + 1. (Ezek mennek a verziókezelő rendszer.) A _version_history_ asztal, valami hasonló

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

kap egy új bejegyzést, valahányszor egy frissítést szkript fut, amely megfelel az új verzióra.

Ez biztosítja, hogy könnyen belátható, hogy milyen verziójú adatbázis séma létezik, és adatbázis-frissítési szkriptek futnak csak egyszer. Ismételten, ezek nem tárol guba. Ehelyett minden script képviseli változásokat kell mozgatni az egyik változata a másikra. Ők a script, amit alkalmazni, hogy a termelési adatbázis „upgrade” azt.

Fejlesztői sandbox szinkronizálás

  1. A script, hogy hát, tisztán tartható, és csökken a termelési adatbázis. Futtatni ezt követően minden frissítést a termelés DB.
  2. A script helyreállítása (és a csípés, ha szükséges) a tartalék egy fejlesztő munkaállomás. Minden fejlesztő futtatja ezt a forgatókönyvet után frissíteni a termelési DB.

A kikötés: Saját automatizált teszteket futtatnak, a séma helyes, de üres adatbázist, így ezt a tanácsot nem tökéletesen megfelel az igényeinek.

Válaszolt 02/08/2008 18:33
a forrás felhasználó

szavazat
10

Azt nem említette valamit megtudni célkörnyezetében vagy kényszert, így ez nem lehet teljes egészében alkalmazható ... de ha keres egy módja annak, hogy hatékonyan nyomon fejlődő DB séma, és nem káros az ötletet, hogy az Ruby, ActiveRecord a vándorlások egészen a sikátorban.

Bevándorlás programozottan határozza tárol transzformációk alkalmazásával Ruby DSL; Minden transzformációs lehet alkalmazni, vagy (általában) visszafordítani, amely lehetővé teszi, hogy ugrani egy másik változata a DB séma bármely adott időpontban. A fájl meghatározó ilyen transzformációk bejelentkezett verzió ellenőrzés, mint bármely más darab forráskódját.

Mivel vándorlások része ActiveRecord , ezek általában használhatók a teljes stack Rails alkalmazások; Azonban, akkor ActiveRecord független Rails minimális erőfeszítéssel. Lásd itt egy részletesebb kezelése az AR a vándorlás kívül Rails.

Válaszolt 02/08/2008 18:54
a forrás felhasználó

szavazat
5

A tipikus megoldás dump az adatbázisban a szükséges biztonsági és azokat a fájlokat.

Attól függően, hogy fejlesztési platform, lehet, hogy opensource plugins elérhető. Gördülő saját kódját kell csinálni általában meglehetősen triviális.

Megjegyzés: Érdemes lehet hát az adatbázis dump ahelyett, hogy a verzió ellenőrzése. A fájlok kap hatalmas gyorsan verzió ellenőrzése járhat, és az egész forrás rendszer lesz lassú (én emlékeztetve a CVS rémtörténet pillanatában).

Válaszolt 03/08/2008 02:49
a forrás felhasználó

szavazat
11

Te is nézd meg a migráció megoldás. Ezek lehetővé teszik, hogy adja meg adatbázissémát C # kódot, és forgassa az adatbázis verzióját fel és le a MSBuild.

Én jelenleg használ DbUp , és ez már jól működik.

Válaszolt 06/08/2008 23:51
a forrás felhasználó

szavazat
6

Mi nem tároljuk az adatbázis sémáját, tároljuk a változásokat az adatbázisba. Mit teszünk, tárolja a séma úgy változik, hogy építünk egy változás script bármely változata az adatbázis, és alkalmazza azt a megrendelő adatbázisok. Írtam egy adatbázis segédprogram app, hogy lesz elosztva a fő alkalmazás, amely képes olvasni a forgatókönyvet, és tudja, hogy mely frissítéseket kell alkalmazni. Azt is elég ész frissíteni nézetek és tárolt eljárások, ha szükséges.

Válaszolt 07/08/2008 00:00
a forrás felhasználó

szavazat
14

Az általunk használt DBGhost kezelni a SQL adatbázisba. Majd ezt követően a script, hogy egy új adatbázist a verziókövetés, és akkor sem, hogy egy új adatbázist, vagy bővíteni meglévő adatbázis a séma verzió ellenőrzés. Így nem kell aggódnia létrehozásának változás szkriptek (bár akkor is csinálni, hogy ha például meg akarja változtatni az adattípus egy oszlop és kell átalakítani adatok).

Válaszolt 07/08/2008 22:12
a forrás felhasználó

szavazat
7

Ha van egy kis adatbázis, és azt szeretné, hogy a teljes verzió a dolgot, ez a batch scriptet segíthet. Elválik, tömöríti, és ellenőrzi a MSSQL adatbázis MDF fájlt a Subversion.

Ha inkább szeretné változata a sémát, és csak kis mennyiségű referencia adatokat, akkor esetleg használatához szubszonikus Bevándorlás kezelni ezt. Az előny van, hogy könnyen vándorolnak felfelé vagy lefelé valamelyik változatát.

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

szavazat
5

Mi csak most kezdődött el Team Foundation Server. Ha az adatbázis közepes méretű, akkor a Visual Studio van néhány szép projekt integrációk beépített össze, az adatok összehasonlítása, adatbázis refactoring eszközök, adatbázis vizsgálat keretében, és még az adatok generációs eszközökkel.

De ez a modell nem illik nagyon nagy, vagy harmadik fél adatbázisok (hogy titkosítani objektumok) nagyon jól. Szóval, amit tettünk, hogy tárolja csak a testre szabott tárgyakat. Visual Studio / Team Foundation Server nagyon jól működik, hogy.

TFS Adatbázis vezető ív. blog

MS TFS helyszínen

Válaszolt 22/08/2008 18:13
a forrás felhasználó

szavazat
42

Red Gate SQL összehasonlítása a termék nem csak lehetővé teszi, hogy ne objektum szintű összehasonlításokat, és ezáltal a változás szkripteket, de azt is lehetővé teszi, hogy az export az adatbázis objektumokat egy mappahierarchiát által szervezett objektum típusát, egy [ObjectName] .sql létrehozása script per tárgya ezekben a könyvtárakban. Az objektum-típusú hierarchia, mint ez:

\ Funkciók
\ Security
\ Security \ szerepkörök
\ Security \ sémák
\ Security \ Users
\ Tárolt eljárások
\ Asztal

Ha lerakó parancsfájlokat gyökérkönyvtárba azután, hogy változtatott, akkor használja ezt frissítéséhez SVN repo, és folyamatosan futó története minden objektum külön-külön.

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

szavazat
4

Egy ideje, találtam egy VB bas modul, amely használt DMO és VSS tárgyakat, hogy egy egész db megírt ki és be VSS. Azt fordult be a VB Script és írt, hogy itt . Ön könnyen vegye ki a VSS hívásokat, és használja a DMO dolgokat létrehozni az összes szkriptet, majd hívja SVN ugyanabból batch fájlt, amely meghívja a VBScript, hogy ellenőrizze őket?

Dave J

Válaszolt 16/09/2008 18:55
a forrás felhasználó

szavazat
20

Érdemes megnézni Liquibase ( http://www.liquibase.org/ ). Még ha nem használja a szerszám maga kezeli a fogalmakat az adatbázis változások kezelése vagy újraszervezi elég jól.

Válaszolt 16/09/2008 19:16
a forrás felhasználó

szavazat
7

Mivel a app dolgozni több RDBMS tárolunk a sémadefiníciós verzióban az irányítást az adatbázis-semleges Torque formátumban (XML). Azt is verzió-ellenőrzés a referenciaadatokat adatbázisunkban XML formátumban a következő (ahol a „kapcsolat” az egyik a referencia táblázatok):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Ezután használja a saját nevelésű eszköz ahhoz, hogy a séma frissítés és referencia adatok aktualizáló szkriptek, amelyek szükségesek, hogy menjen a változat X az adatbázis verzió X + 1.

Válaszolt 24/09/2008 06:49
a forrás felhasználó

szavazat
12

Ez egy jó megközelítés, hogy mentse adatbázis szkripteket verziókezelő váltással szkriptek, így frissíteni bármelyike ​​adatbázisban van. Szintén érdemes megmenteni sémák különböző változatai, így lehet létrehozni egy teljes adatbázis anélkül, hogy alkalmazza az összes változás szkripteket. Kezelés A scriptek automatizálni kell, hogy nem kell tennie kézi munkát.

Szerintem fontos, hogy egy külön adatbázist minden fejlesztő, és nem használ egy megosztott adatbázist. Így a fejlesztők is készíthetnek teszt esetek és fejlesztési fázis függetlenül más fejlesztők.

Az automatizálási eszköz legyen eszközt kezelő adatbázis metaadat, ami megmondja, hogy mit adatbázisok milyen fejlettségi és amely táblázatok változat szabályozható adatokat és így tovább.

Válaszolt 24/09/2008 07:11
a forrás felhasználó

szavazat
7

Ahhoz, hogy a lerakó egy forráskód ellenőrző rendszer, hogy kicsit gyorsabb, akkor láthatja, hogy mely objektumokat óta megváltoztak utoljára használatával verzió információ sysobjects.

Beállítás: Hozzon létre egy táblázatot minden adatbázisban ellenőrizni kívánt fokozatosan, hogy tartsa a verzió információkat utoljára ellenőriztük (üres az első futás). Törölje ezt a táblázatot, ha azt szeretnénk, hogy újra átvizsgálja az egész adatszerkezet.

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Normál működési mód: Tudod venni az eredmények e sql, és ezáltal sql szkriptek csak az Önt érdekli, és tedd őket egy forrás kontroll, amelyet választott.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT IGNORE  #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT IGNORE  last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Megjegyzés: Ha egy nem szabványos egybevetés kapcsolatba az adatbázisokat, akkor ki kell cserélni /* COLLATE */az adatbázis egybevetés. azazCOLLATE Latin1_General_CI_AI

Válaszolt 24/09/2008 13:53
a forrás felhasználó

szavazat
6

Mi volt a szükségességét változat a SQL adatbázis után átálltunk az x64 platform és a régi verzió szakított a migráció. Írtunk egy C # alkalmazás, amely használható Sqldmo, hogy feltérképezzék az összes SQL objektumok egy mappát:

                Gyökér
                    Szerver név
                       Adatbázis név
                          sémaobjektumok
                             Adatbázis indítja *
                                .ddltrigger.sql
                             Funkciók
                                ..function.sql
                             Biztonság
                                szerepek
                                   alkalmazás szerepek
                                      .approle.sql
                                   adatbázis szerepek
                                      .role.sql
                                sémák *
                                   .schema.sql
                                felhasználók
                                   .user.sql
                             Tárolás
                                Teljes szöveg katalógusok *
                                   .fulltext.sql
                             tárolt eljárások
                                ..proc.sql
                             Szinonimák *
                                .synonym.sql
                             asztalok
                                ..table.sql
                                Korlátok
                                   ... chkconst.sql
                                   ... defconst.sql
                                indexek
                                   ... index.sql
                                Kulcsok
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                Eseményindítók
                                   ... trigger.sql
                             típusai
                                Felhasználó által definiált adattípusok
                                   ..uddt.sql
                                XML séma gyűjtemények *
                                   ..xmlschema.sql
                             Nézetek
                                ..view.sql
                                indexek
                                   ... index.sql
                                Eseményindítók
                                   ... trigger.sql

Az alkalmazás ezután össze az újonnan írott változata a tárolt verzióra SVN és ha vannak is eltérések aktualizálja SVN. Megállapítottuk, hogy fut a folyamat egyszer este volt elegendő, mivel nem teszünk, hogy sok változás az SQL. Ez lehetővé teszi számunkra, hogy a változások nyomon követése, hogy az összes objektum törődünk plusz lehetővé teszi számunkra, hogy újjáépítsék a teljes séma esetén komoly probléma.

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

szavazat
17

1 mindenkinek, aki ajánlotta a Redgate eszközökkel, egy újabb ajánlás és egy ellentmondás.

SqlCompare is egy tisztességesen dokumentált API: így például levelet konzol alkalmazás, amely szinkronizálja a forrás által vezérelt Scripts mappában egy CI integrációs tesztelés adatbázis checkin, hogy ha valaki bejelentkezik változás a sémát a szkriptek mappa ez automatikusan telepítésre, továbbá a megfelelő alkalmazás kódját változás. Ez segít felzárkózni a fejlesztők, akik elfelejtik mintegy szaporító változások a helyi db akár közös fejlesztési DB (mintegy fele minket, szerintem :)).

A kikötés az, hogy egy forgatókönyvben megoldás, vagy más módon, az Redgate eszközök kellően sima, hogy ez könnyű elfelejteni SQL valóság alapjául szolgáló absztrakció. Ha átnevezi az összes oszlopot a táblázatban, SqlCompare nincs módja annak, hogy feltérképezzük a régi oszlopokat az új oszlopokat, és vidd az összes adatot a táblázatban. Ez generál figyelmeztetéseket, de láttam az emberek rákattintanak, hogy a múlt. Van egy általános kérdés itt érdemes, azt hiszem, hogy csak akkor lehet automatizálni DB verziókezelő és frissíteni eddig - az absztrakciók nagyon lyukas.

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

szavazat
4

Én is egy olyan verzióját használja az adatbázisban tárolt adatbázis útján kiterjesztett tulajdonságok családnak eljárásokat. Saját alkalmazás szkriptek egyes verzió lépés (azaz. Mozog 1,1-1,2). Ha telepített, úgy néz ki, a jelenlegi verziót, majd fut a script egyesével, amíg el nem éri az utolsó alkalmazás verziója. Nincs forgatókönyv, amely az egyenes „végleges” változat, még telepíteni egy tiszta DB működik a telepíthető sorozat révén frissítési lépésekkel.

Most mit szeretek hozzá, hogy láttam két nappal ezelőtt egy előadást az MS campus az új és a következő VS DB kiadás. Az előadás középpontjában kifejezetten ebben a témában, és én fújja ki a vizet. Akkor feltétlenül nézd meg az új létesítmények középpontjában tartani sémadefiníciós T-SQL szkriptek (teremt), futtatási delta motort összehasonlítani telepítési séma meghatározott séma, és ezzel a delta megváltoztatja és integráció forráskód integráció, akár beleértve MSBuild folyamatos integrációja automatikus építmények csepp. A csepp tartalmazni fog egy új fájltípus a .dbschema fájlokat, amelyeket meg lehet tenni, hogy a telepítési hely és egy parancssori eszköz lehet csinálni a tényleges „delták”, és futtassa a telepítést. Van egy blog bejegyzést ebben a témában, kapcsolatban áll a VSDE letöltések, akkor nézd meg őket: http://rusanu.com/2009/05/15/version-control-and-your-database/

Válaszolt 15/05/2009 20:26
a forrás felhasználó

szavazat
8

Ez egyszerű.

  1. Ha a bázis projekt készen, akkor létre kell hozni a teljes adatbázis script. Ez a szkript elkötelezett az SVN. Ez az első verzió.

  2. Ezután minden fejlesztő létrehoz változás szkripteket (ALTER ..., új táblázatok, sprocs, stb.)

  3. Ha szükség van a jelenlegi verzió, akkor meg kell végrehajtani az összes új változás szkripteket.

  4. Amikor az alkalmazás kiadott termelési akkor megy vissza 1 (de akkor ez lesz az egymást követő változata természetesen).

Nant segít végrehajtani azokat változás szkripteket. :)

És emlékezz. Minden jól működik, ha van fegyelem. Minden alkalommal, amikor az adatbázis változás elkötelezett majd megfelelő funkciókat kód elkötelezettek is.

Válaszolt 16/05/2009 12:31
a forrás felhasználó

szavazat
9

Minden adatbázis alatt kell lennie forráskód ellenőrzés. Mi hiányzik egy olyan eszköz automatikusan script minden adatbázis-objektumok - és „konfigurációs adatok” - fájlba, ami aztán lehet hozzá bármilyen forrásból rendszer. Ha az SQL Server, akkor a megoldás itt van: http://dbsourcetools.codeplex.com/ . Érezd jól magad. - Nathan.

Válaszolt 07/07/2009 13:58
a forrás felhasználó

szavazat
2

Az én tapasztalatom szerint a megoldás kettős:

  1. Meg kell kezelni változásokat a fejlődés adatbázis végzik több fejlesztő a fejlesztés során.

  2. Meg kell kezelni adatbázis frissítéseket ügyfelek oldalakon.

Annak érdekében, hogy kezelni # 1 szüksége lesz egy erős adatbázis diff / merge eszköz. A legjobb eszköz, képesnek kell lennie arra, hogy végre automatikus egyesítése, amennyire csak lehet, miközben lehetővé teszi, hogy megoldja kezelt konfliktusok kézzel.

A tökéletes eszközt kell kezelni egyesíteni műveletek segítségével 3-utas algoritmusa, hogy hozza véve a változások történtek az övék adatbázis és a bánya adatbázis, a bázishoz képest tárol.

Írtam egy kereskedelmi eszköz, amely a kézi egyesítés támogatása SQLite adatbázisokhoz, és én jelenleg hozzátéve, támogatja a 3-utas egyesítési algoritmus SQLite. Ellenőrizze, hogy ki http://www.sqlitecompare.com

Annak érdekében, hogy kezelni # 2 akkor szüksége lesz egy frissítés kerettől.

Az alapötlet az, hogy dolgozzon ki egy automatikus frissítési keretet, amely tudja, hogyan kell frissíteni egy meglévő SQL séma az újabb SQL séma és építhet frissítési lehetőséget minden létező DB telepítést.

Nézd meg a cikket a témában http://www.codeproject.com/KB/database/sqlite_upgrade.aspx , hogy egy általános képet, amit én beszélek.

Sok szerencsét

Liron Levi

Válaszolt 06/08/2009 11:28
a forrás felhasználó

szavazat
2

Távozás DBGhost http://www.innovartis.co.uk/ . Én használtam automatizált módon 2 éve, és ez remekül működik. Ez lehetővé teszi, hogy a DB épít történni, mint egy Java vagy C építmények történik, kivéve az adatbázisban. Tudod, mire gondolok.

Válaszolt 02/11/2009 23:17
a forrás felhasználó

szavazat
22

Itt a Red Kapu kínálunk egy eszköz, SQL Source Control , amely az SQL összehasonlítása technológiát összekapcsolni az adatbázis egy TFS vagy SVN repository. Ez az eszköz integrálható SSMS és lehetővé teszi a munkát, ahogy általában, kivéve, hogy most lehetővé teszi elkövetni a tárgyakat.

Egy vándorlások alapú megközelítés (több alkalmas automatizált telepítések) kínálunk ReadyRoll , amely létrehozza és kezeli egy sor egyedi szkriptek, mint a Visual Studio projekt.

Az SQL Source Control lehetőség van megadni a statikus táblázat adatait. Ezek tárolják forrás ellenőrzés INSERT MELLŐZ nyilatkozatokat.

Ha beszélünk a vizsgálatok adatai, azt javasoljuk, hogy vagy generálni vizsgálati adatokat egy eszköz vagy egy telepítés utáni script határozná meg, vagy egyszerűen csak visszaállítani a termelés hát a dev környezetet.

Válaszolt 01/07/2010 10:10
a forrás felhasználó

szavazat
6

Írtam ezt az alkalmazást egy ideje, http://sqlschemasourcectrl.codeplex.com/ amely átvizsgálja a MSFT SQL DB, ahányszor csak akar, és automatikusan lerakó objektumok (táblák, nézetek, speciális képessége, függvények, sql beállítások) be SVN. Úgy működik, mint a karikacsapás. Tudom használni Unfuddle (amely lehetővé teszi számomra, hogy figyelmeztető jelzések checkins)

Válaszolt 23/09/2010 03:35
a forrás felhasználó

szavazat
5

Egyetértek Esv válasz, és hogy a pontos oka, kezdett egy kicsit projekt egy kicsit vissza, hogy segítsen fenntartani az adatbázis frissítése, egy nagyon egyszerű fájl, amelyet aztán fenntartotta a hosszú oldalon ki forráskódot. Ez lehetővé teszi a könnyű frissítéseket a fejlesztők, valamint UAT és termelés. Az eszköz működik, de SQL Server és MySql.

Néhány projekt jellemzői:

  • Lehetővé sémamódosításokat
  • Lehetővé érték fa lakosság
  • Lehetővé teszi, hogy külön vizsgálati adatok betétek pl. UAT
  • Lehetővé teszi, hogy lehetőség rollback (nem automata)
  • Fenntartja támogatás SQL szerver és a MySQL
  • Képes importálni a meglévő adatbázist verzió ellenőrzés egyetlen paranccsal (SQL Server csak ... még mindig dolgoznak mysql)

A kód a házigazdája a google kódot. Kérjük, látogasson el a Google kódot némi információt

http://code.google.com/p/databaseversioncontrol/

Válaszolt 24/02/2011 19:28
a forrás felhasználó

szavazat
14

A VS 2010 az adatbázison projekt.

  1. Script ki az adatbázis
  2. Módosítások szkriptek vagy közvetlenül a db szerver
  3. Szinkronizáláshoz használja az Adatok> séma összehasonlítása

Teszi a tökéletes DB verziószámozást oldattal és szinkronizálását teszi DB gyerekjáték.

Válaszolt 25/02/2011 21:18
a forrás felhasználó

szavazat
3

Ez egy nagyon régi kérdés, de sokan próbálják megoldani ezt még most is. Mindössze annyit kell tennie, hogy a kutatás a Visual Studio Database projektek. Enélkül minden adatbázis fejlesztés néz ki, nagyon gyenge. Code szervezet telepítési verziókövetés, egyszerűsíti mindent.

Válaszolt 23/06/2015 11:26
a forrás felhasználó

szavazat
37

Először ki kell választani a verziókezelő rendszert, hogy igaza van az Ön számára:

  • Központosított Version Control rendszer - a szabványos rendszer, ahol a felhasználók nézd meg / check-in előtt / után dolgozni fájlokat, és a fájlokat tárolnak egy központi szerver

  • Elosztott verziókezelő rendszer - egy olyan rendszer, ahol a tár klónozás, és minden egyes klón valójában a teljes biztonsági másolatot a tárolóban, így ha a kiszolgáló összeomlik, akkor bármelyik klónozott tároló használható visszaállítani kiválasztása után a megfelelő rendszer az Ön igényeinek , akkor be kell állítanod az adattár, amely a szíve minden verziókövető rendszer Mindez összefügg a következő cikkben: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -source-control-alapjai /

Miután létrehoztunk egy tároló, és abban az esetben a központi verziókövető rendszer egy működő mappát, akkor olvassa el ezt a cikket . Ez azt mutatja, hogyan állítsd forrás vezérlő egy olyan fejlesztői környezet segítségével:

  • SQL Server Management Studio segítségével a MSSCCI szolgáltató,

  • Visual Studio és az SQL Server Data Tools

  • A 3rd party eszköz ApexSQL Source Control
Válaszolt 24/06/2015 10:36
a forrás felhasználó

szavazat
1

Azt javasoljuk, hogy használja összehasonlító eszközök improvizálni egy verziókövető rendszer az adatbázis. Egy jó alternatíva van xSQL séma összehasonlítása és xSQL adatok összehasonlítása .

Most, ha a cél az, hogy csak az adatbázis séma alapján verziókezelő egyszerűen használható xSQL séma összehasonlítása generálni xSQL pillanatképei a séma és a hozzá ezeket a fájlokat a verzió ellenőrzése. Than, hogy visszatérjen, vagy frissítsd egy speciális változatát csak összehasonlítani az aktuális verzió az adatbázist a pillanatkép a rendeltetési hely változat.

Sajnos, ha azt szeretné, hogy az adatok alapján verzió ellenőrzése is, akkor használja xSQL adatok összehasonlítása generálni változás szkripteket az Ön adatbázis és adjuk hozzá a .sql fájlokat a verzió ellenőrzése. Lehet majd végrehajtani ezeket a szkripteket, hogy visszatérjen / frissítés minden változata, amit akar. Tartsuk szem előtt, hogy a „visszaállítás” funkciót kell létrehoznia változás szkripteket, hogy amikor végre fogja tenni 3-as verzió ugyanaz, mint a 2-es verzió és a „frissítés” funkciót, akkor létre kell hoznia a változás szkriptek nem az ellenkezőjét.

Végül néhány alapvető tétel programozási ismeretek lehet automatizálni az egész folyamatot a parancssor segítségével változatai xSQL séma összehasonlítása és xSQL adatok összehasonlítása

Fontos: én csatlakozott xSQL.

Válaszolt 10/01/2017 16:16
a forrás felhasználó

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