Wie kann ich die Versionskontrolle eines Datenbankschemas durchführen?

Question

Gibt es weg (billig oder FLOSS) zu tun Versionskontrolle von SQL Server 2008 DB-Schema?

Answer 1

Hier ist ein schöner Artikel von Jeff Atwood über Datenbank-Versionskontrolle

Sie können verwenden Team-Edition für Datenbankexperten zu diesem Zweck

Hier ist ein Liste der Werkzeuge die Sie kaufen können und die auch verwendet werden können:

Red Gate SQL Vergleichen ab $295.

DB Ghost ab $195

SQL Change Manager $995 pro Instanz.

SQL-Effekte Clarity Standardausgabe ab $139

SQLSourceSafe ab $129.

sqlXpress Diff Kontakt für Preis :-(

Embarcadero Change Manager Kontakt für Preis :-(

Apex SQL Diff ab $399

SQL Versionsverwaltung 2003 ab $199

SASSI v2.0 professionell von $180

Evorex Source # Shareware oder $299+ (widersprüchliche Berichte!)

Editar Ich habe gerade diesen Beitrag gefunden, der die Versionskontrolle durch svn erklärt: Versionierung der SQL Server-Datenbank

Answer 2

Erstellen Sie in Visual Studio ein Datenbankprojekt für die Datenbank. Checken Sie dieses Projekt in ein Bibliothekssystem ein, z. B. SVN oder Team Foundation Server.

Answer 3

Meiner Erfahrung nach gibt es in einer Unternehmensumgebung keine einfache Option.

Die drei nachstehenden Methoden sind die wichtigsten (unabhängig vom verwendeten Werkzeugsatz).

1) Das gesamte Schema in eine Datei auslagern und die Datei im Repository speichern

PROS: Einfach

CONS: Große Datei - schwer manuell zu bearbeiten - schwer zu sehen, was sich seit der letzten Version geändert hat - kann nicht bereitgestellt werden, daher bräuchte man einen Mechanismus, um ein DIFF-Skript zwischen Entwicklungs- und Test-/Live-Systemen vorzubereiten

2) Jedes Datenbankobjekt in eine separate Datei auslagern, die im Repository gespeichert wird.

PROS: Sehr einfach zu sehen, was sich geändert hat. Kann für die meisten Objekte problemlos Deployment-Skripte erstellen (obwohl einige Dinge immer noch ein DIFF-Skript erfordern würden, z. B. Änderungen der Spaltendefinition)

CONS: Die Skripte müssen in einer bestimmten Reihenfolge ausgeführt werden - die Verwaltung dieses Prozesses kann recht schwierig sein.

3) Behandeln Sie jede Änderung als einen separaten Vorgang mit einem eigenen, fortlaufend nummerierten SQL-Skript.

PROS: Einfache Erstellung von Skripten für Entwickler, gleiche Skripte können auf jeder Plattform ausgeführt werden (theoretisch)

CONS: Alptraum zu verwalten - Ordnung kann ein Problem werden, sehr schwierig zu sehen, was in einer Version geändert hat, oder wann ein bestimmtes Objekt geändert wurde.

Nachdem ich alle 3 Optionen ausprobiert habe, würde ich sagen, dass 2 sehr angenehm zu arbeiten war, aber es dauerte ewig, um es überhaupt einzurichten - alle Skripte in der richtigen Reihenfolge auszuführen dauerte ewig - und es erforderte immer noch die Verwendung eines Datenbank-Diff-Tools, um Skripte für UAT/Live zu generieren. Daher würde ich jetzt eine Mischung aus 1 und 2 empfehlen.