Datenbank-Quellcodeverwaltung vs.Schemaänderungsskripte

Question

Der Aufbau und die Pflege einer Datenbank, die dann von vielen Entwicklern bereitgestellt/weiterentwickelt wird, ist ein ständiger Prozess in der Softwareentwicklung.Wir erstellen ein Build-Skript und verwalten weitere Aktualisierungsskripte, die angewendet werden, wenn die Datenbank im Laufe der Zeit wächst.Es gibt viele Möglichkeiten, dies zu verwalten, von manuellen Updates bis hin zu Konsolen-Apps/Build-Skripts, die dabei helfen, diese Prozesse zu automatisieren.

Hat jemand, der diese Prozesse erstellt/verwaltet hat, auf eine Quellcodeverwaltungslösung für die Datenbankschemaverwaltung umgestellt?Wenn ja, was ist Ihrer Meinung nach die beste Lösung?Gibt es Fallstricke, die vermieden werden sollten?

Red Gate scheint ein großer Player in der MSSQL-Welt zu sein und seine DB-Quellcodeverwaltung sieht sehr interessant aus:http://www.red-gate.com/products/solutions_for_sql/database_version_control.htm

Obwohl es nicht so aussieht, als würde es den (Standard-)Datenverwaltungsprozess ersetzen, ersetzt es aus meiner Sicht nur die Hälfte des Änderungsverwaltungsprozesses.

(Wenn ich von Daten spreche, meine ich Suchwerte und dergleichen, Daten, die standardmäßig oder in einem DR-Szenario bereitgestellt werden müssen)

Wir arbeiten in einer .Net/MSSQL-Umgebung, aber ich bin sicher, dass die Prämisse in allen Sprachen gleich ist.

Answer 1

Ähnliche Fragen

Eine oder mehrere dieser vorhandenen Fragen könnten hilfreich sein:

• Der beste Weg, Datenbankänderungen zu verwalten, ändert sich
• MySQL Datenbank ändern Tracking
• SQL Server-Datenbank Workflow Best Practices
• Datenbankänderungen (Versionssteuerung)
• Übertragen von Änderungen von einem dev dB auf eine Produktion Db
• Verfolgung von Änderungen in der Datenbankstruktur

oder eine Suche nach Datenbankwechsel

Answer 2

Ich betreue ein von der Bank, in der ich arbeite, selbst entwickeltes Data Warehouse.Dies erfordert ständige Aktualisierungen und wir haben ein Team von 2-4 Entwicklern, die daran arbeiten.

Wir haben das Glück, dass es nur eine einzige Instanz unseres „Produkts“ gibt, sodass wir uns nicht um die Bereitstellung auf mehreren Instanzen kümmern müssen, die möglicherweise unterschiedliche Versionen haben.

Wir führen für jedes Objekt (Tabelle, Ansicht, Index, gespeicherte Prozedur, Trigger) in der Datenbank eine Erstellungsskriptdatei.

Wir vermeiden die Verwendung von ALTER TABLE Wenn möglich, benennen Sie lieber eine Tabelle um, erstellen Sie eine neue und migrieren Sie die Daten.Das bedeutet, dass wir nicht die Geschichte durchsehen müssen ALTER Skripte – wir können immer die aktuelle Version jeder Tabelle sehen, indem wir uns das Erstellungsskript ansehen.Die Migration wird durch ein separates Migrationsskript durchgeführt – dieses kann teilweise automatisch generiert werden.

Jedes Mal, wenn wir eine Veröffentlichung durchführen, verfügen wir über ein Skript, das die Erstellungs-/Migrationsskripte in der entsprechenden Reihenfolge ausführt.

Zu Ihrer Information:Wir verwenden Visual SourceSafe (igitt!) zur Quellcodeverwaltung.

Answer 3

Ich habe nach einem SQL Server-Quell-Control-Tool gesucht und stößt auf viele Premium-Versionen, die den Job durchführen - mit SQL Server Management Studio als Plugin verwenden.

LIQUIBASE ist ein kostenloser, aber ich habe es nie ganz für meine Bedürfnisse gearbeitet.

Es gibt dort ein weiteres freies Produkt, obwohl dies funktioniert, von SSMS und Skripts von Objekten und Daten in flacher Dateien auszusetzen.

Diese Objekte können dann in eine neue SQL Server-Instanz gepumpt werden, die dann die Datenbankobjekte neu erstellt.

siehe gitsql

Answer 4

Vielleicht fragen Sie nach liquiBase ?