Verwenden Sie die Quellcodeverwaltung für Ihre Datenbankelemente? [geschlossen]

Ich habe das Gefühl, dass mein Shop eine Lücke hat, weil wir keinen soliden Prozess für die Versionierung unserer Datenbankschemaänderungen haben. Wir machen viele Backups, damit wir mehr oder weniger abgedeckt sind, aber es ist eine schlechte Praxis, sich auf diese Weise auf Ihre letzte Verteidigungslinie zu verlassen.

Überraschenderweise scheint dies ein roter Faden zu sein. Viele Geschäfte, mit denen ich gesprochen habe, ignorieren dieses Problem, weil sich ihre Datenbanken nicht oft ändern und sie im Grunde nur versuchen, akribisch zu sein.

Ich weiß jedoch, wie diese Geschichte verläuft. Es ist nur eine Frage der Zeit, bis die Dinge falsch laufen und etwas verloren geht.

Gibt es dafür Best Practices? Welche Strategien haben sich für Sie bewährt?

Muss lesen Holen Sie sich Ihre Datenbank unter Versionskontrolle . Überprüfen Sie die Reihe von Beiträgen von K. Scott Allen.

Wenn es um die Versionskontrolle geht, ist die Datenbank häufig ein Bürger zweiter oder sogar dritter Klasse. Nach allem, was ich gesehen habe, können Teams, die in einer Million Jahren niemals daran denken würden, Code ohne Versionskontrolle zu schreiben - und das zu Recht -, die Notwendigkeit einer Versionskontrolle für die kritischen Datenbanken, auf die sich ihre Anwendungen verlassen, völlig vergessen. Ich weiß nicht, wie Sie sich als Softwareentwickler bezeichnen und ein ernstes Gesicht bewahren können, wenn Ihre Datenbank nicht genau der gleichen strengen Quellcodeverwaltung unterliegt wie der Rest Ihres Codes. Lass dir das nicht passieren. Holen Sie sich Ihre Datenbank unter Versionskontrolle.

Die Datenbanken selbst? Nein

Die Skripte, die sie erstellen, einschließlich statischer Dateneinfügungen, gespeicherter Prozeduren und dergleichen; Na sicher. Es sind Textdateien, sie sind im Projekt enthalten und werden wie alles andere ein- und ausgecheckt.

In einer idealen Welt würde Ihr Datenbankverwaltungstool dies natürlich tun. aber man muss nur diszipliniert sein.

Ich liebe Rails ActiveRecord-Migrationen. Es abstrahiert die DML in ein Ruby-Skript, das dann einfach in Ihrem Quell-Repository versioniert werden kann.

Mit ein wenig Arbeit könnten Sie jedoch das Gleiche tun. Alle DDL-Änderungen (ALTER TABLE usw.) können in Textdateien gespeichert werden. Behalten Sie ein Nummerierungssystem (oder einen Datumsstempel) für die Dateinamen bei und wenden Sie sie nacheinander an.

Rails verfügt außerdem über eine 'version'-Tabelle in der Datenbank, die die zuletzt angewendete Migration verfolgt. Sie können das gleiche leicht tun.

In LiquiBase können Sie Datenbankänderungen mithilfe der Quellcodeverwaltung verwalten.

Sie sollten sich niemals einfach anmelden und "ALTER TABLE" -Befehle eingeben, um eine Produktionsdatenbank zu ändern. Das Projekt, an dem ich arbeite, verfügt über eine Datenbank an jedem Kundenstandort. Daher wird jede Änderung an der Datenbank an zwei Stellen vorgenommen: einer Speicherauszugsdatei, mit der eine neue Datenbank an einem neuen Kundenstandort erstellt wird, und einer Aktualisierungsdatei, die ausgeführt wird bei jedem Update, bei dem Ihre aktuelle Datenbankversionsnummer mit der höchsten Nummer in der Datei verglichen und Ihre Datenbank an Ort und Stelle aktualisiert wird. So zum Beispiel die letzten Updates:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Ich bin sicher, es gibt einen besseren Weg, dies zu tun, aber es hat bisher für mich funktioniert.

Ja. Code ist Code. Meine Faustregel lautet, dass ich in der Lage sein muss, die Anwendung von Grund auf neu zu erstellen und bereitzustellen , ohne auf eine Entwicklungs- oder Produktionsmaschine schauen zu müssen.

Die beste Vorgehensweise, die ich gesehen habe, ist das Erstellen eines Erstellungsskripts zum Verschrotten und Wiederherstellen Ihrer Datenbank auf einem Staging-Server. Jede Iteration erhielt einen Ordner für Datenbankänderungen, alle Änderungen wurden mit "Drop ... Create" skriptiert. Auf diese Weise können Sie jederzeit ein Rollback auf eine frühere Version durchführen, indem Sie den Build auf den Ordner verweisen, in den Sie die Version erstellen möchten.

Ich glaube, das wurde mit NaNt / CruiseControl gemacht.

JA, ich denke, es ist wichtig, Ihre Datenbank zu versionieren. Nicht die Daten, aber das Schema mit Sicherheit.

In Ruby On Rails wird dies vom Framework mit "Migrationen" behandelt. Jedes Mal, wenn Sie die Datenbank ändern, erstellen Sie ein Skript, das die Änderungen anwendet, und checken es in die Quellcodeverwaltung ein.

Meinem Shop hat diese Idee so gut gefallen, dass wir die Funktionalität unseres Java-basierten Builds mithilfe von Shell-Skripten und Ant hinzugefügt haben . Wir haben den Prozess in unsere Bereitstellungsroutine integriert. Es wäre ziemlich einfach, Skripte zu schreiben, um dasselbe in anderen Frameworks zu tun, die die sofort einsatzbereite DB-Versionierung nicht unterstützen.

Die neuen Datenbankprojekte in Visual Studio bieten Quellcodeverwaltung und Änderungsskripts.

Sie haben ein nettes Tool, das Datenbanken vergleicht und ein Skript generieren kann, das das Schema von einem in das andere konvertiert oder die Daten in einem aktualisiert, um mit dem anderen übereinzustimmen.

Das Datenbankschema wird "geschreddert", um viele, viele kleine SQL-Dateien zu erstellen, eine pro DDL-Befehl, der die Datenbank beschreibt.

+ tom

Zusätzliche Informationen 30.11.2008

Ich benutze es seit einem Jahr als Entwickler und mag es wirklich. Es macht es einfach, meine Entwicklungsarbeit mit der Produktion zu vergleichen und ein Skript für die Veröffentlichung zu generieren. Ich weiß nicht, ob Funktionen fehlen, die DBAs für Projekte vom Typ "Unternehmen" benötigen.

Da das Schema in SQL-Dateien "zerkleinert" wird, funktioniert die Quellcodeverwaltung einwandfrei.

Ein Problem ist, dass Sie eine andere Denkweise haben müssen, wenn Sie ein Datenbankprojekt verwenden. Das Tool verfügt über ein "Datenbankprojekt" in VS, bei dem es sich nur um SQL handelt, sowie eine automatisch generierte lokale Datenbank, die das Schema und einige andere Administratordaten enthält - jedoch keine Ihrer Anwendungsdaten sowie Ihre lokale Entwicklerdatenbank, für die Sie sie verwenden App Daten Entwickler arbeiten. Sie kennen die automatisch generierte Datenbank selten, aber Sie müssen sie dort kennen, damit Sie sie in Ruhe lassen können :). Diese spezielle Datenbank ist deutlich erkennbar, da sie einen Guid im Namen hat.

Das VS DB-Projekt leistet gute Arbeit bei der Integration von Datenbankänderungen, die andere Teammitglieder vorgenommen haben, in Ihr lokales Projekt / die zugehörige Datenbank. Sie müssen jedoch den zusätzlichen Schritt unternehmen, um das Projektschema mit Ihrem lokalen dev db-Schema zu vergleichen und die Mods anzuwenden. Es macht Sinn, aber es scheint zunächst unangenehm.

DB-Projekte sind ein sehr leistungsfähiges Werkzeug. Sie generieren nicht nur Skripte, sondern können diese sofort anwenden. Stellen Sie sicher, dass Sie Ihre Produktionsdatenbank damit nicht zerstören. ;)

Ich mag die VS DB-Projekte sehr und ich erwarte, dieses Tool in Zukunft für alle meine Datenbankprojekte zu verwenden.

+ tom

Die Anforderung an die Entwicklungsteams, ein SQL-Datenbank-Quellcodeverwaltungssystem zu verwenden, ist kein Wundermittel, das das Auftreten von Problemen verhindert. Die Datenbank-Quellcodeverwaltung führt zu einem zusätzlichen Overhead, da die Entwickler die an einem Objekt vorgenommenen Änderungen in einem separaten SQL-Skript speichern, den Client des Quellcodeverwaltungssystems öffnen, die SQL-Skriptdatei mit dem Client einchecken und dann Übernehmen Sie die Änderungen auf die Live-Datenbank.

Ich kann vorschlagen, das SSMS-Add-In namens ApexSQL Source Control zu verwenden . Entwickler können damit problemlos Datenbankobjekte mit dem Quellcodeverwaltungssystem über den Assistenten direkt von SSMS aus zuordnen. Das Add-In unterstützt TFS, Git, Subversion und andere SC-Systeme. Es enthält auch Unterstützung für die Quellcodeverwaltung von statischen Daten.

Klicken Sie nach dem Herunterladen und Installieren von ApexSQL Source Control einfach mit der rechten Maustaste auf die Datenbank, für die Sie die Versionskontrolle durchführen möchten, und navigieren Sie zum Untermenü ApexSQL Source Control in SSMS. Klicken Sie auf die Option Datenbank mit Quellcodeverwaltung verknüpfen, wählen Sie das Quellcodeverwaltungssystem und das Entwicklungsmodell aus. Danach müssen Sie die Anmeldeinformationen und die Repository-Zeichenfolge für das von Ihnen ausgewählte Quellcodeverwaltungssystem angeben.

Sie können diesen Artikel für weitere Informationen lesen: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Ich speichere / aktualisiere Skripte und ein Skript, das Sampledata generiert.

Ja, wir behalten dazu unser SQL als Teil unseres Builds bei - wir behalten DROP.sql, CREATE.sql, USERS.sql, VALUES.sql und die Versionskontrolle bei, damit wir zu jeder getaggten Version zurückkehren können.

Wir haben auch Ameisenaufgaben, die die Datenbank bei Bedarf neu erstellen können.

Außerdem wird die SQL zusammen mit dem dazugehörigen Quellcode markiert.

Das erfolgreichste Schema, das ich jemals für ein Projekt verwendet habe, hat Backups und differenzielle SQL-Dateien kombiniert. Grundsätzlich würden wir nach jeder Veröffentlichung eine Sicherungskopie unserer Datenbank erstellen und einen SQL-Dump erstellen, damit wir bei Bedarf auch ein leeres Schema von Grund auf neu erstellen können. Wenn Sie dann eine Änderung an der Datenbank vornehmen müssen, fügen Sie dem SQL-Verzeichnis unter Versionskontrolle einen Änderungsskript hinzu. Wir würden dem Dateinamen immer eine Sequenznummer oder ein Datum voranstellen, sodass die erste Änderung etwa 01_add_created_on_column.sql lautet und das nächste Skript 02_added_customers_index lautet. Unser CI-Computer prüft diese und führt sie nacheinander auf einer neuen Kopie der Datenbank aus, die aus der Sicherung wiederhergestellt wurde.

Wir hatten auch einige Skripte eingerichtet, mit denen Entwickler ihre lokale Datenbank mit einem einzigen Befehl auf die aktuelle Version neu initialisieren konnten.

Wir steuern alle von unserer Datenbank erstellten Objekte. Und nur um die Entwickler ehrlich zu halten (weil Sie Objekte erstellen können, ohne dass sie sich in der Quellcodeverwaltung befinden), suchen unsere dbas regelmäßig nach Objekten, die sich nicht in der Quellcodeverwaltung befinden. Wenn sie etwas finden, löschen sie es, ohne zu fragen, ob es in Ordnung ist.

Ich verwende SchemaBank , um alle meine Datenbankschemaänderungen zu versionieren :

• Ab dem ersten Tag importiere ich meinen Datenbankschema-Dump hinein
• Ich begann mein Schemadesign mit einem Webbrowser zu ändern (weil sie SaaS / Cloud-basiert sind).
• Wenn ich meinen Datenbankserver aktualisieren möchte, generiere ich das Änderungsskript (SQL) daraus und wende es auf die Datenbank an. In der Schemabank wird ich beauftragt, meine Arbeit als Version zu übernehmen, bevor ich ein Aktualisierungsskript erstellen kann. Ich mag diese Art von Übung, damit ich immer zurückverfolgen kann, wenn ich muss.

Unsere Teamregel lautet, NIEMALS den Datenbankserver direkt zu berühren, ohne vorher die Entwurfsarbeit zu speichern. Aber es kommt vor, dass jemand versucht sein könnte, die Regel zu brechen, um es bequemer zu machen. Wir würden den Schema-Dump erneut in die Schema-Bank importieren und ihn das Diff machen lassen und jemanden schlagen, wenn eine Diskrepanz gefunden wird. Obwohl wir die Änderungsskripte daraus generieren könnten, um unser Datenbank- und Schemadesign synchron zu machen, hassen wir das einfach.

Übrigens können wir damit auch Zweige innerhalb des Versionskontrollbaums erstellen, damit ich einen für die Bereitstellung und einen für die Produktion verwalten kann. Und eine zum Codieren von Sandboxen.

Ein hübsches, webbasiertes Schema-Design-Tool mit Versionskontrolle und Änderungsverwaltung.

Ich habe alles Notwendige, um meine Datenbank aus Bare-Metal neu zu erstellen, abzüglich der Daten selbst. Ich bin mir sicher, dass es viele Möglichkeiten gibt, dies zu tun, aber alle meine Skripte und dergleichen werden in Subversion gespeichert, und wir können die DB-Struktur und dergleichen neu erstellen, indem wir all das aus der Subversion herausziehen und ein Installationsprogramm ausführen.

Normalerweise erstelle ich für jede Änderung, die ich vornehme, ein SQL-Skript und ein anderes, um diese Änderungen rückgängig zu machen und diese Skripte unter Versionskontrolle zu halten.

Dann haben wir die Möglichkeit, bei Bedarf eine neue, aktuelle Datenbank zu erstellen, und können problemlos zwischen den Revisionen wechseln. Jedes Mal, wenn wir eine Version erstellen, werden die Skripte zusammengefasst (erfordert ein wenig manuelle Arbeit, ist aber selten wirklich schwierig ), sodass wir auch eine Reihe von Skripten haben, die zwischen Versionen konvertiert werden können.

Ja, bevor Sie es sagen, ist dies sehr ähnlich zu dem, was Rails und andere tun, aber es scheint ziemlich gut zu funktionieren, also habe ich keine Probleme zuzugeben, dass ich die Idee schamlos aufgehoben habe :)

Ich verwende SQL CREATE-Skripte, die aus MySQL Workbech exportiert wurden, und verwende dann die "Export SQL ALTER" -Funktionalität. Am Ende habe ich eine Reihe von Erstellungsskripten (natürlich nummeriert) und die Änderungsskripte, mit denen die Änderungen zwischen ihnen angewendet werden können.

3.- SQL-ALTER-Skript exportieren Normalerweise müssten Sie die ALTER TABLE-Anweisungen jetzt von Hand schreiben, um Ihre Änderungen am Modell widerzuspiegeln. Aber Sie können klug sein und Workbench die harte Arbeit für Sie erledigen lassen. Wählen Sie einfach Datei -> Exportieren -> Forward Engineer SQL ALTER Script… aus dem Hauptmenü.

Dadurch werden Sie aufgefordert, die SQL CREATE-Datei anzugeben, mit der das aktuelle Modell verglichen werden soll.

Wählen Sie das SQL CREATE-Skript aus Schritt 1 aus. Das Tool generiert dann das ALTER TABLE-Skript für Sie und Sie können dieses Skript für Ihre Datenbank ausführen, um es auf den neuesten Stand zu bringen.

Sie können dies mit dem MySQL Query Browser oder dem MySQL-Client tun. Voila! Ihr Modell und Ihre Datenbank wurden jetzt synchronisiert!

Quelle: MySQL Workbench Community Edition: Handbuch zur Schemasynchronisierung

Alle diese Skripte befinden sich natürlich unter Versionskontrolle.

Ja immer. Sie sollten in der Lage sein, Ihre Produktionsdatenbankstruktur bei Bedarf mit einem nützlichen Satz von Beispieldaten neu zu erstellen. Wenn Sie dies nicht tun, werden im Laufe der Zeit kleinere Änderungen vergessen, um die Dinge am Laufen zu halten, und eines Tages werden Sie gebissen, große Zeit. Es ist eine Versicherung, die Sie vielleicht nicht für nötig halten, aber an dem Tag, an dem Sie sie machen, ist sie den zehnfachen Preis wert!

Es wurde viel über das Datenbankmodell selbst diskutiert, aber wir speichern die erforderlichen Daten auch in .SQL-Dateien.

Um beispielsweise nützlich zu sein, benötigt Ihre Anwendung möglicherweise Folgendes bei der Installation:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Wir hätten eine Datei, die currency.sqlunter Subversion aufgerufen wird . Als manuellen Schritt im Erstellungsprozess vergleichen wir die vorherige Währung.sql mit der neuesten und schreiben ein Upgrade-Skript.

Wir versionieren und kontrollieren alles rund um unsere Datenbanken:

• DDL (erstellen und ändern)
• DML (Referenzdaten, Codes usw.)
• Datenmodelländerungen (mit ERwin oder ER / Studio)
• Änderungen der Datenbankkonfiguration (Berechtigungen, Sicherheitsobjekte, allgemeine Konfigurationsänderungen)

Wir tun dies alles mit automatisierten Jobs, die Change Manager und einige benutzerdefinierte Skripte verwenden. Wir haben Change Manager, der diese Änderungen überwacht und benachrichtigt, wenn sie abgeschlossen sind.

Ich glaube, dass jede Datenbank unter Quellcodeverwaltung sein sollte und Entwickler eine einfache Möglichkeit haben sollten, ihre lokale Datenbank von Grund auf neu zu erstellen. Inspiriert von Visual Studio für Datenbankprofis habe ich ein Open-Source-Tool erstellt, das Skripts für MS SQL-Datenbanken erstellt und diese auf einfache Weise für Ihre lokale DB-Engine bereitstellt. Versuchen Sie es mit http://dbsourcetools.codeplex.com/ . Viel Spaß, - Nathan.

Wenn Ihre Datenbank SQL Server ist, haben wir möglicherweise genau die Lösung, nach der Sie suchen. SQL Source Control 1.0 wurde jetzt veröffentlicht.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Dies wird in SSMS integriert und stellt den Klebstoff zwischen Ihren Datenbankobjekten und Ihrem VCS bereit. Das "Scripting out" erfolgt transparent (es verwendet die SQL Compare-Engine unter der Haube), was die Verwendung so einfach machen sollte, dass Entwickler nicht davon abgehalten werden, den Prozess zu übernehmen.

Eine alternative Visual Studio-Lösung ist ReadyRoll , die als Untertyp des SSDT-Datenbankprojekts implementiert ist. Dies erfordert einen migrationsgesteuerten Ansatz, der besser auf die Automatisierungsanforderungen von DevOps-Teams zugeschnitten ist.

Ich steuere das Datenbankschema als Quellcodeverwaltung, indem ich alle Objekte (Tabellendefinitionen, Indizes, gespeicherte Prozeduren usw.) ausschreibe. Verlassen Sie sich für die Daten selbst einfach auf regelmäßige Sicherungen. Dies stellt sicher, dass alle strukturellen Änderungen mit dem richtigen Revisionsverlauf erfasst werden, belastet die Datenbank jedoch nicht bei jeder Datenänderung.

In unserem Geschäft verwenden wir Datenbankänderungsskripte. Wenn ein Skript ausgeführt wird, wird sein Name in der Datenbank gespeichert und nicht erneut ausgeführt, es sei denn, diese Zeile wird entfernt. Skripte werden basierend auf Datum, Uhrzeit und Code-Verzweigung benannt, sodass eine kontrollierte Ausführung möglich ist.

Viele, viele Tests werden durchgeführt, bevor die Skripte in der Live-Umgebung ausgeführt werden. Daher werden "Oopsies" im Allgemeinen nur in Entwicklungsdatenbanken durchgeführt.

Wir sind dabei, alle Datenbanken in die Quellcodeverwaltung zu verschieben. Wir verwenden sqlcompare, um die Datenbank zu skripten (leider eine Funktion der Profession Edition) und dieses Ergebnis in SVN zu speichern.

Der Erfolg Ihrer Implementierung hängt stark von der Kultur und den Praktiken Ihres Unternehmens ab. Die Leute hier glauben daran, eine Datenbank pro Anwendung zu erstellen. Es gibt eine Reihe allgemeiner Datenbanken, die von den meisten Anwendungen verwendet werden und viele Abhängigkeiten zwischen den Datenbanken verursachen (einige davon sind zirkulär). Das Einfügen der Datenbankschemata in die Quellcodeverwaltung war aufgrund der Abhängigkeiten zwischen den Datenbanken unserer Systeme bekanntermaßen schwierig.

Viel Glück für Sie, je früher Sie es ausprobieren, desto eher werden Sie Ihre Probleme lösen.

Ich habe das dbdeploy-Tool von ThoughtWorks unter http://dbdeploy.com/ verwendet . Es wird die Verwendung von Migrationsskripten empfohlen. In jeder Version haben wir die Änderungsskripte in einer einzigen Datei zusammengefasst, um das Verständnis zu erleichtern und es DBAs zu ermöglichen, die Änderungen zu "segnen".

Das war auch für mich immer ein großer Ärger - es scheint einfach viel zu einfach zu sein, eine schnelle Änderung an Ihrer Entwicklungsdatenbank vorzunehmen, sie zu speichern (zu vergessen, ein Änderungsskript zu speichern), und dann stecken Sie fest. Sie können das, was Sie gerade getan haben, rückgängig machen und wiederholen, um das Änderungsskript zu erstellen, oder es von Grund auf neu schreiben, wenn Sie möchten, obwohl dies viel Zeit für das Schreiben von Skripten bedeutet.

Ein Tool, das ich in der Vergangenheit verwendet habe und das dabei geholfen hat, ist SQL Delta. Es zeigt Ihnen die Unterschiede zwischen zwei Datenbanken (SQL Server / Oracle, glaube ich) und generiert alle Änderungsskripte, die für die Migration von A-> B erforderlich sind. Eine weitere nette Sache ist, alle Unterschiede zwischen dem Datenbankinhalt zwischen der Produktions- (oder Test-) Datenbank und Ihrer Entwicklungs-Datenbank anzuzeigen. Da immer mehr Apps die Konfiguration und den Status speichern, die für ihre Ausführung in Datenbanktabellen entscheidend sind, kann es sehr schwierig sein, Änderungsskripte zu verwenden, mit denen die richtigen Zeilen entfernt, hinzugefügt und geändert werden. SQL Delta zeigt die Zeilen in der Datenbank so an, wie sie in einem Diff-Tool aussehen würden - geändert, hinzugefügt, gelöscht.

Ein ausgezeichnetes Werkzeug. Hier ist der Link: http://www.sqldelta.com/

RedGate ist großartig, wir generieren neue Snapshots, wenn Datenbankänderungen vorgenommen werden (eine winzige Binärdatei) und behalten diese Datei als Ressource in den Projekten. Wann immer wir die Datenbank aktualisieren müssen, verwenden wir das RedGate-Toolkit, um die Datenbank zu aktualisieren und neue Datenbanken aus leeren zu erstellen.

RedGate erstellt auch Daten-Snapshots, obwohl ich nicht persönlich mit ihnen gearbeitet habe, sie sind genauso robust.

Zu Ihrer Information Dies wurde auch vor einigen Tagen von Dana angesprochen ... Gespeicherte Prozeduren / DB-Schema in der Quellcodeverwaltung