Versiebeheer SQL Server-database

stemmen
288

Ik wil mijn databases te krijgen onder versiebeheer. Heeft iemand enig advies of aanbeveling artikelen aan me begon te krijgen?

Ik zal altijd willen op zijn minst een aantal gegevens in er (als alumb vermeldt: types gebruikers en beheerders). Ik zal ook willen vaak een grote collectie gegenereerd testgegevens voor prestatiemetingen.

De vraag is gesteld op 01/08/2008 om 19:33
bron van user
In andere talen...                            


29 antwoorden

stemmen
169

Martin Fowler schreef mijn favoriete artikel over het onderwerp, http://martinfowler.com/articles/evodb.html . Ik kies schema stort in onder versie controle niet te zetten alumb en anderen suggereren, want ik wil een eenvoudige manier om mijn productie database te upgraden.

Voor een webapplicatie waar ik een enkele productie-database-exemplaar zult hebben, gebruik ik twee technieken:

Database Upgrade Scripts

Een sequentiedatabank upgradescripts de DDL te bevatten die het schema van versie N naar N + 1. (Deze gaan in je versie controle systeem.) Een _version_history_ tafel, iets als

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

krijgt een nieuwe ingang elke keer een upgrade script die overeenkomt met de nieuwe versie.

Dit zorgt ervoor dat het gemakkelijk is om te zien welke versie van de database schema bestaat en dat de database-upgrade scripts worden slechts één keer uit te voeren. Nogmaals, dit zijn niet de database stortplaatsen. Integendeel, elk script staat voor de veranderingen die nodig zijn om van de ene versie naar de volgende. Ze zijn het script dat u op uw productie database om "upgraden" het.

Developer Sandbox Synchronisatie

  1. Een script voor back-up, ontsmetten en krimpen een productie-database. Voer dit na elke upgrade naar de productie DB.
  2. Een script te herstellen (en tweak, indien nodig) de back-up op de werkplek van een ontwikkelaar. Elke ontwikkelaar loopt dit script na elke upgrade naar de productie DB.

Een waarschuwing: Mijn geautomatiseerde tests uitvoeren op een schema-correct, maar lege database, dus dit advies zal niet perfect past bij uw behoeften.

antwoordde op 02/08/2008 om 18:33
bron van user

stemmen
42

Rode Poort SQL Vergelijk product kunt u niet alleen om object-level vergelijkingen te doen, en het genereren van verandering scripts van dat, maar het maakt het ook mogelijk om uw database-objecten exporteren naar een mappenstructuur georganiseerd door het type object, met één [objectnaam] .sql creatie script per object in deze mappen. Het objecttype hiërarchie is als volgt:

\ Functies
\ Security
\ Security \ Roles
\ Security \ schema
\ Security \ Users
\ Stored Procedures
\ Tables

Als u uw scripts dumpen naar dezelfde hoofdmap nadat u wijzigingen aanbrengt, kunt u dit gebruiken om uw SVN repo te werken, en houdt een lopende geschiedenis van elk afzonderlijk object.

antwoordde op 26/08/2008 om 08:23
bron van user

stemmen
38

Dit is één van de "harde problemen" rond ontwikkeling. Voor zover ik weet zijn er geen perfecte oplossingen.

Als je alleen nodig om de database structuur en niet de gegevens op te slaan kunt u de database te exporteren als SQL-queries. (In Enterprise Manager: Klik met de rechtermuisknop op de database -> Generate SQL script dat ik raden u aan "het creëren van een bestand per object" op het tabblad opties.) U kunt dan plegen deze tekstbestanden SVN en gebruik maken van diff en logging functies SVN.

Ik heb dit aan elkaar gebonden met een batch script dat een paar parameters neemt en stelt de database. Ik heb ook een aantal aanvullende vragen die standaard gegevens in te voeren, zoals types gebruiker en de admin gebruiker toegevoegd. (Als u meer informatie over dit wilt, post iets en ik kan het script ergens toegankelijk te zetten)

Als u alle gegevens goed te houden, adviseer ik het bijhouden van een back-up van de database en het gebruik van Redgate ( http://www.red-gate.com/ ) producten aan de vergelijkingen te doen. Ze zijn niet goedkoop, maar ze zijn elke cent waard.

antwoordde op 01/08/2008 om 20:28
bron van user

stemmen
37

Ten eerste, moet u de versie controle systeem dat geschikt is voor u te kiezen:

  • Gecentraliseerde Version Control-systeem - een standaard systeem waarbij gebruikers check out / check-in voor / na ze werken aan bestanden, en de bestanden worden in één centrale server worden bewaard

  • Distributed versie controle systeem - een systeem waarbij de repository wordt gekloond en elke kloon is eigenlijk de volledige back-up van de repository, dus als een server crasht, dan is elke gekloonde repository kan worden gebruikt om het te herstellen Na het kiezen van het juiste systeem voor uw behoeften , moet u het instellen van de repository dat is de kern van elke versie controle systeem dit alles wordt uitgelegd in het volgende artikel: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding -source-control-basics /

Na het opzetten van een repository, en in het geval van een centrale versie controle systeem een werkmap, leest u dit artikel . Het laat zien hoe u de bron controle in een ontwikkelomgeving met:

  • SQL Server Management Studio via de MSSCCI provider,

  • Visual Studio en SQL Server Data Gereedschap

  • Een 3rd party hulpmiddel ApexSQL Source Control
antwoordde op 24/06/2015 om 10:36
bron van user

stemmen
22

Hier bij Red Gate bieden wij een tool, SQL Source Control , die SQL Vergelijk technologie gebruikt om uw database te koppelen aan een TFS of SVN repository. Deze tool integreert in SSMS en laat je werken als je normaal zou, behalve dat het nu kunt u de objecten te plegen.

Voor een migratie-aanpak (meer geschikt voor geautomatiseerde implementaties), bieden wij ReadyRoll , die creëert en beheert een reeks van incrementele scripts als een Visual Studio project.

In SQL Source Control is het mogelijk om statische gegevens tabellen op te geven. Deze worden opgeslagen in de bron te beheersen als INSERT IGNORE statements.

Als je het over testgegevens, raden we dat je ofwel testgegevens genereren met een gereedschap of via een post-deployment script u definieert, of als u gewoon een productie-back-up naar de dev milieu te herstellen.

antwoordde op 01/07/2010 om 10:10
bron van user

stemmen
20

Je zou willen kijken naar Liquibase ( http://www.liquibase.org/ ). Zelfs als je niet het gereedschap zelf te gebruiken zorgt voor de concepten van de database change management of refactoring vrij goed.

antwoordde op 16/09/2008 om 19:16
bron van user

stemmen
17

+1 voor iedereen die is aan te raden de Redgate gereedschappen, met een extra aanbeveling en een waarschuwing.

SqlCompare heeft ook een fatsoenlijk gedocumenteerd API: dus je kan bijvoorbeeld, schrijf een console app die synchroniseert uw bron scripts gecontroleerd map met een CI integratie testen databank op checkin, zodat wanneer iemand controleert in een wijziging in het schema van hun scripts map dit wordt vervolgens toegepast tezamen met de bijbehorende toepassingscode veranderen. Dit helpt de kloof met de ontwikkelaars die vergeetachtig zijn over het propageren van veranderingen in hun lokale db tot een gezamenlijke ontwikkeling DB (ongeveer de helft van ons, denk ik :)).

Een nadeel is dat met een gescripte oplossing of anderszins de Redgate gereedschap voldoende glad dat het gemakkelijk vergeten SQL werkelijkheid achter de abstractie. Als u de naam van alle kolommen in een tabel, SqlCompare heeft geen manier om de oude kolommen toewijzen aan de nieuwe kolommen en worden alle gegevens te laten vallen in de tabel. Het zal waarschuwingen genereren, maar ik heb gezien dat mensen klikken verleden dat. Er is een algemeen punt hier de moeite waard om, denk ik, dat je alleen kunt automatiseren DB versiebeheer en tot nu toe upgraden - de abstracties zijn zeer lekkende.

antwoordde op 15/10/2008 om 10:44
bron van user

stemmen
14

Met VS 2010, gebruik maken van de database project.

  1. Script uit uw database
  2. Wijzigingen aanbrengen in scripts of direct op uw db server
  3. Synchroniseren met behulp van Data> Schema Vergelijk

Maakt een perfecte DB versiebeheer oplossing, en maakt het synchroniseren van DB is een koud kunstje.

antwoordde op 25/02/2011 om 21:18
bron van user

stemmen
14

We gebruiken DBGhost om onze SQL-database te beheren. Dan zet je je scripts om een nieuwe database op te bouwen in uw versie controle, en het zal ook het bouwen van een nieuwe database, of een upgrade van een bestaande database om het schema in versie controle. Op die manier hoef je niet zorgen te maken over het maken van veranderingen scripts (hoewel je kunt nog steeds doen, als u bijvoorbeeld wilt het datatype van een kolom te wijzigen en de noodzaak om gegevens om te zetten).

antwoordde op 07/08/2008 om 22:12
bron van user

stemmen
12

Het is een goede benadering van de database scripts in versie controle met verandering scripts opslaan, zodat u elk één database je kunt upgraden. Ook wilt u misschien schema's voor verschillende versies op te slaan, zodat u een volledige database kan maken zonder de verandering scripts toe te passen. Omgaan met de scripts zou moeten worden geautomatiseerd, zodat u niet hoeft te handmatig werk te doen.

Ik denk dat het belangrijk is om een ​​aparte database voor elke ontwikkelaar en een gedeelde database niet gebruiken. Op die manier de ontwikkelaars kunnen testgevallen en ontwikkelingsfase onafhankelijk te maken van andere ontwikkelaars.

Het automatiseren instrument moet middel voor de behandeling van de database metadata, die vertelt wat databases zijn in welke staat van de ontwikkeling en die tabellen bevatten versie controleerbare gegevens en ga zo maar door.

antwoordde op 24/09/2008 om 07:11
bron van user

stemmen
11

U kunt ook kijken naar een migraties oplossing. Hiermee kunt u uw database schema in C # -code te specificeren, en rol je versie van de database op en neer met behulp van MSBuild.

Ik ben momenteel met behulp DbUp , en het is goed werkt.

antwoordde op 06/08/2008 om 23:51
bron van user

stemmen
10

U heeft geen details over uw doelgroep milieu of beperkingen op te noemen, dus dit kan niet helemaal van toepassing zijn ... maar als je op zoek bent naar een manier om effectief te volgen een zich ontwikkelende DB-schema en zijn niet nadelig is voor het idee van het gebruik Ruby, ActiveRecord's migraties zijn iets voor jou.

Migraties programmatisch databank transformaties met behulp van een Ruby DSL te definiëren; elke transformatie kan worden toegepast of (meestal) teruggedraaid, zodat u om naar een andere versie van uw DB-schema op een bepaald punt in de tijd. Het bestand definiëren van deze transformaties kunnen worden gecontroleerd in versie controle als elk ander stuk van de broncode.

Omdat migraties zijn een deel van ActiveRecord , vinden ze meestal gebruik in full-stack Rails apps; U kunt echter ActiveRecord onafhankelijk van Rails te gebruiken met een minimale inspanning. Zie hier voor een meer gedetailleerde behandeling van het gebruik van AR's migraties buiten Rails.

antwoordde op 02/08/2008 om 18:54
bron van user

stemmen
9

Elke databank moet onder source-code controle. Wat ontbreekt is een tool om automatisch script alle database-objecten - en "configuratiegegevens" - naar een bestand, die vervolgens naar een willekeurige bron besturingssysteem kan worden toegevoegd. Als u gebruik maakt van SQL Server, dan is mijn oplossing is hier: http://dbsourcetools.codeplex.com/ . Veel plezier. - Nathan.

antwoordde op 07/07/2009 om 13:58
bron van user

stemmen
8

Het is makkelijk.

  1. Wanneer de basis project klaar is, dan moet u de volledige database-script te creëren. Dit script is toegewijd aan SVN. Het is in de eerste versie.

  2. Na dat alle ontwikkelaars creëert verandering scripts (ALTER ..., nieuwe tafels, sprocs, etc).

  3. Als je huidige versie nodig hebt dan moet je alle nieuwe verandering scripts uit te voeren.

  4. Wanneer app is vrijgegeven voor productie dan ga je terug naar 1 (maar dan zal het opeenvolgende versie natuurlijk).

Nant zal u helpen om deze veranderingen scripts uit te voeren. :)

En onthoud. Alles werkt prima wanneer er discipline. Iedere keer als de database verandering is toegewijd dan overeenkomstige functies in de code zijn ook gepleegd.

antwoordde op 16/05/2009 om 12:31
bron van user

stemmen
7

Om de stortplaats te brengen in een broncode besturingssysteem dat beetje sneller, kunt u zien welke objecten zijn veranderd sinds de laatste keer met behulp van de versie-informatie in sysobjects.

Setup: Maak een tabel in elke database die u wilt stapsgewijs controleren van de versie informatie van de laatste keer dat je gecontroleerd (leeg op de eerste run) vast te houden. Wis deze tabel als u opnieuw wilt scannen uw hele datastructuur.

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)
)

Normaal lopen modus: U kunt de resultaten uit dit sql, en het genereren van sql scripts voor slechts degene die je geïnteresseerd bent, en leg ze in een bron controle van uw keuze.

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

Opmerking: Als u een niet-standaard sorteren wilt gebruiken in een van uw databases, dient u te vervangen /* COLLATE */met uw database collatie. d.w.zCOLLATE Latin1_General_CI_AI

antwoordde op 24/09/2008 om 13:53
bron van user

stemmen
7

Omdat onze app moet werken over meerdere RDBMSs, slaan we ons schema definitie in versie controle met behulp van de database-neutrale Torque formaat (XML). We hebben ook versie-controle van de referentiegegevens voor onze database in XML-formaat als volgt (waar de "relatie" is één van de referentie-tabellen):

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

Vervolgens gebruiken we zelfgekweekte tools waarmee u het genereren van de schema-upgrade en referentiegegevens te upgraden scripts die nodig zijn om van versie X van de database versie X + 1.

antwoordde op 24/09/2008 om 06:49
bron van user

stemmen
7

Als u een kleine database en u wilt versie het hele ding, deze batch script zou kunnen helpen. Het los, comprimeert, en controleert een MSSQL-database MDF-bestand in Subversion.

Als je vooral wilt versie uw schema en hebben gewoon een kleine hoeveelheid van de referentie-gegevens, kunt u eventueel gebruik maken van SubSonic Migraties te hanteren dat. Het voordeel is dat je gemakkelijk kunnen migreren omhoog of omlaag om een specifieke versie.

antwoordde op 07/08/2008 om 22:21
bron van user

stemmen
6

Ik schreef dit app een tijdje geleden, http://sqlschemasourcectrl.codeplex.com/ die scant uw MSFT SQL db's zo vaak als je wilt en automatisch dump je objecten (tabellen, views, ontwerp en bouw, functies, sql-instellingen) in SVN. Werkt perfect. Ik gebruik het met Unfuddle (die me in staat stelt om waarschuwingen op checkins te krijgen)

antwoordde op 23/09/2010 om 03:35
bron van user

stemmen
6

We hadden de noodzaak om versie onze SQL-database nadat we gemigreerd naar een x64-platform en onze oude versie brak met de migratie. We schreven een C # applicatie die SQLDMO gebruikt om in kaart te brengen alle van de SQL-objecten naar een map:

                Wortel
                    Server naam
                       Database naam
                          schema Objecten
                             Database Triggers *
                                .ddltrigger.sql
                             functies
                                ..function.sql
                             Veiligheid
                                Rollen
                                   Application Roles
                                      .approle.sql
                                   Databaserollen
                                      .role.sql
                                schema *
                                   .schema.sql
                                gebruikers
                                   .user.sql
                             opslagruimte
                                Volledige tekst Catalogs *
                                   .fulltext.sql
                             Opgeslagen procedures
                                ..proc.sql
                             Synoniemen *
                                .synonym.sql
                             tabellen
                                ..table.sql
                                constraints
                                   ... chkconst.sql
                                   ... defconst.sql
                                Indexes
                                   ... index.sql
                                Keys
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                triggers
                                   ... trigger.sql
                             Types
                                Door de gebruiker gedefinieerde Data Types
                                   ..uddt.sql
                                XML Schema Collecties *
                                   ..xmlschema.sql
                             Keer bekeken
                                ..view.sql
                                Indexes
                                   ... index.sql
                                triggers
                                   ... trigger.sql

De applicatie zou vervolgens vergelijken met de nieuw geschreven versie naar de versie opgeslagen in SVN en als er verschillen waren zou het SVN werken. We hebben vastgesteld dat het uitvoeren van het proces een keer per nacht was voldoende omdat we niet maken dat veel veranderingen in SQL. Het stelt ons in staat om wijzigingen in alle objecten die we de zorg over te houden plus het stelt ons in staat om onze volledige schema weer op te bouwen in het geval van een ernstig probleem.

antwoordde op 09/10/2008 om 15:54
bron van user

stemmen
6

We hebben niet de database schema te slaan we de wijzigingen in de database op te slaan. Wat wij doen is het schema wijzigingen op te slaan, zodat we bouwen aan een verandering script voor elke versie van de database en toe te passen op databases van onze klanten. Ik schreef een database-programma app die wordt verspreid met onze belangrijkste applicatie die dat script kan lezen en weten welke updates moeten worden toegepast. Het heeft ook genoeg smarts om views en stored procedures te vernieuwen als dat nodig is.

antwoordde op 07/08/2008 om 00:00
bron van user

stemmen
5

Ik ga akkoord met ESV antwoord en dat exacte reden dat ik begonnen met een klein project een tijdje terug voor het behoud van database-updates in een zeer eenvoudige bestand dat vervolgens source code kan worden vastgehouden aan een lange kant naar buiten. Het maakt een eenvoudige updates voor ontwikkelaars als UAT en productie. De tool werkt op maar SQL Server en MySQL.

Enkele project kenmerken:

  • Hiermee schema veranderingen
  • Allows value bomenbestand
  • Laat afzonderlijke testgegevens inzetstukken voor bv. UAT
  • Hiermee optie voor rollback (niet geautomatiseerd)
  • Onderhoudt ondersteuning voor SQL server en mysql
  • Heeft de mogelijkheid om uw bestaande database importeren in versie controle met een simpele commando (SQL Server alleen ... nog steeds bezig met mysql)

De code wordt gehost op Google Code. Kijk dan op Google code voor wat meer informatie

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

antwoordde op 24/02/2011 om 19:28
bron van user

stemmen
5

We zijn net begonnen met behulp van Team Foundation Server. Als uw database is middelgroot, dan Visual Studio heeft een aantal mooie project integraties met ingebouwde vergelijken, gegevens te vergelijken, database refactoring gereedschappen, database toetsingskader, en zelfs data generatie gereedschappen.

Maar, is dat model niet past zeer grote of derde partij databases (die coderen objecten) erg goed. Dus, wat we hebben gedaan is om alleen onze op maat gemaakte objecten op te slaan. Visual Studio / Team Foundation Server werkt zeer goed voor.

TFS Database chief boog. blog

MS TFS website

antwoordde op 22/08/2008 om 18:13
bron van user

stemmen
5

De typische oplossing is om de database te dumpen als nodig is en back-up die bestanden.

Afhankelijk van uw ontwikkelplatform, kunnen er opensource plugins beschikbaar. Rolling uw eigen code om het te doen, is meestal vrij triviaal.

Opmerking: U kunt een back-up van de database dump in plaats van dat het in versie controle. De bestanden kunnen krijgen enorm snel in versie controle, en ervoor zorgen dat uw gehele source besturingssysteem te traag (ik ben het oproepen van een CVS horror verhaal op het moment).

antwoordde op 03/08/2008 om 02:49
bron van user

stemmen
4

Ik ben ook een versie opgeslagen in de database via de database uitgebreide eigenschappen familie van procedures. Mijn toepassing heeft scripts voor elke versie stap (bijv. Bewegen 1,1-1,2). Wanneer deze worden ingezet, wordt gekeken naar de huidige versie en dan loopt de scripts één voor één totdat het de laatste versie van de app bereikt. Er is geen script dat de rechte 'definitieve' versie heeft, zelfs in te zetten op een schone DB doet het implementeren via een reeks upgrade stappen.

Nu wat ik willen toevoegen is dat ik twee dagen geleden een presentatie hebt gezien op de MS campus over de nieuwe en aanstaande VS DB editie. De presentatie was speciaal gericht op dit onderwerp en ik werd uit het water geblazen. Je moet zeker check it out, de nieuwe faciliteiten zijn gericht op het houden van schemadefinitie in T-SQL-scripts (creëert), een runtime-delta motor tot implementatie schema met gedefinieerde schema en het doen van de delta verandert en de integratie met de broncode integratie, tot vergelijken en met MSBuild continue integratie voor geautomatiseerde build druppels. De druppel moet een nieuw bestandstype bevatten, de .dbschema bestanden, die kunnen worden genomen om de inzet site en een command-line tool kan de werkelijke 'delta's' te doen en lopen de inzet. Ik heb een blog over dit onderwerp met links naar de VSDE downloads, moet u controleren ze uit: http://rusanu.com/2009/05/15/version-control-and-your-database/

antwoordde op 15/05/2009 om 20:26
bron van user

stemmen
4

Een tijdje geleden vond ik een VB bas module die gebruikt DMO en VSS voorwerpen een hele db scripted uit en in VSS te krijgen. Ik maakte er een VB Script en postte het hier . Je kan gemakkelijk neem de VSS oproepen en gebruik maken van de DMO spullen om alle scripts te genereren, en bel dan SVN uit dezelfde batch-bestand dat de VBScript oproepen om ze te controleren in?

Dave J

antwoordde op 16/09/2008 om 18:55
bron van user

stemmen
3

Het is een zeer oude vraag is echter veel proberen dit zelfs nu op te lossen. Het enige wat ze hoeft te doen is om het onderzoek over Visual Studio Database Projects. Zonder deze, elke database ontwikkeling ziet er erg zwak. Van code organisatie om uitzending naar versiebeheer, het vereenvoudigt alles.

antwoordde op 23/06/2015 om 11:26
bron van user

stemmen
2

Check out DBGhost http://www.innovartis.co.uk/ . Ik heb gebruikt op een geautomatiseerde manier voor 2 jaar nu en het werkt geweldig. Het laat ons DB bouwt te veel gebeuren als een Java of C build gebeurt, met uitzondering van de database. Je weet wat ik bedoel.

antwoordde op 02/11/2009 om 23:17
bron van user

stemmen
2

In mijn ervaring zijn de oplossing is tweeledig:

  1. U moet wijzigingen in de ontwikkeling database die worden gedaan door meerdere ontwikkelaars tijdens de ontwikkeling te behandelen.

  2. Je moet database-upgrades bij klanten vestigingen verwerken.

Om te verwerken # 1 je een sterke databank diff / merge tool nodig. De beste tool moet in staat zijn om automatisch moeten worden samengevoegd zo veel mogelijk uit te voeren terwijl u conflicten handmatig op te lossen onverwerkte.

Het perfecte gereedschap moeten omgaan samenvoegen operaties met behulp van een 3-weg merge algoritme dat de wijzigingen die zijn aangebracht in de THEIRS database en de MINE database, ten opzichte van het BASE-database in aanmerking brengt.

Ik schreef een commercieel instrument dat handmatig samen te voegen ondersteuning voor SQLite databases biedt en ik ben op dit moment het toevoegen van ondersteuning voor 3-way merge algoritme voor SQLite. Bekijk het op http://www.sqlitecompare.com

Om te verwerken # 2 vindt u een upgrade kader in plaats nodig hebben.

Het basisidee is om een ​​automatische upgrade kader die weet hoe je een upgrade van een bestaande SQL-schema naar de nieuwere SQL schema en kan een upgradepad voor elk bestaand DB installatie bouwen ontwikkelen.

Check out mijn artikel over het onderwerp in http://www.codeproject.com/KB/database/sqlite_upgrade.aspx om een algemeen idee van wat ik het over te krijgen.

Succes

Liron Levi

antwoordde op 06/08/2009 om 11:28
bron van user

stemmen
1

Ik stel met behulp van vergelijking tools om een versie controle systeem improviseren voor uw database. Een goed alternatief zijn xSQL Schema Vergelijk en xSQL gegevens te vergelijken .

Nu, als je doel is om alleen schema van de database onder versie controle hebt, kun je gewoon gebruik maken van xSQL Schema Vergelijk xSQL Snapshots van het schema te genereren en voeg deze bestanden in uw versie controle. Dan, om terug te keren of update naar een specifieke versie gewoon vergelijken met de huidige versie van de database met de snapshot voor de bestemming versie.

Ach, als je wilt om de gegevens onder versie controle net zo goed, kunt u gebruik maken xSQL gegevens te vergelijken om verandering scripts voor u de database te genereren en voeg de Sql-bestanden in uw versie controle. U kunt dan deze scripts uit te voeren om / bijwerken terugkeren om het even welke versie je wilt. Houd er rekening mee dat voor de 'revert' functionaliteit die u nodig hebt om verandering scripts te genereren die, wanneer zal Versie 3 hetzelfde als Version 2 en voor de 'update' functionaliteit maken, moet je verandering scripts die het tegenovergestelde te doen genereren.

Ten slotte, met een aantal elementaire batch programmeren vaardigheden die je kunt het hele proces te automatiseren met behulp van de command line versies van xSQL Schema Vergelijk xSQL gegevens te vergelijken

Disclaimer: Ik ben aangesloten bij xSQL.

antwoordde op 10/01/2017 om 16:16
bron van user

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