Frage:
Tools zum Verwalten und Bereitstellen von Datenbankschemata und Daten für SQL Server?
Kenny Evitt
2014-02-05 22:09:40 UTC
view on stackexchange narkive permalink

Ich möchte das Schema und die 'statischen' Daten einer SQL Server-Datenbank als Code in einem Versionskontrollsystem beibehalten. Ich möchte auch in der Lage sein, bestimmte Versionen des Datenbankcodes für tatsächliche Instanzen der relevanten Datenbank bereitzustellen, dh eine Datenbank auf eine neue Version zu migrieren (und optional auf eine alte Version herunterzuwandern).

Erklärung

Datenbanken

Ich gehe davon aus, dass ich nicht erklären muss, was eine Datenbank ist oder dass SQL Server ist ein bestimmtes Datenbanksystem, dh eine bestimmte Software zum Verwalten von Datenbanken.

Datenbankschema als Code

Unter Softwareentwicklern, die mit Datenbanken arbeiten, ist es Es ist wünschenswert, das ' Schema' einer Datenbank, dh Informationen über ihre Struktur, in Form von ' Code' verwalten zu können. Dieser Code sollte es jemandem ermöglichen, eine Datenbank mit demselben 'Schema' zu erstellen, das durch den Code dargestellt wird. Der Code könnte in Form von DDL-Anweisungen ( Data Definition Language) vorliegen, z. SQL -Code, normalerweise in einer herstellerspezifischen Version davon, der zum Erstellen von Objekten wie Tabellen und Indizes in einer Datenbank verwendet wird in einer allgemeinen Programmiersprache sein, z Java, Ruby, C # usw.

Versionskontrolle und Code

Einmal das Schema Wenn eine Datenbank in Code dargestellt ist, kann dieser Code in einer Versionskontrolle oder einem Versionskontrollsystem, einer Software zur Verwaltung der Revisionskontrolle, verwaltet werden. Aus Wikipedia:

Die Revisionskontrolle, auch als Versionskontrolle und Quellcodeverwaltung (und ein Aspekt der Softwarekonfigurationsverwaltung) bezeichnet, ist die Verwaltung von Änderungen an Dokumenten, Computerprogrammen, großen Websites und andere Informationssammlungen.

Das Verwalten von Code, der das Schema einer Datenbank in einem Versionskontrollsystem darstellt, ist wünschenswert, da ein Verlauf der Änderungen am Schema beibehalten werden kann und andere Tools, wie die Tools, nach denen ich in dieser Frage frage, darauf zugreifen können das Schema, auch verschiedene Versionen des Schemas, für andere Zwecke.

Softwarebereitstellung

' Bereitstellung' im Kontext der Softwareentwicklung und Softwarewartung umfassen "... alle Aktivitäten, die ein Softwaresystem zur Verwendung verfügbar machen". Im Zusammenhang mit dieser Frage interessieren mich Empfehlungen für Softwaretools, mit denen eine bestimmte Version eines Datenbankschemas in Form konkreter spezifischer Instanzen von Datenbanken im SQL Server-DBMS verfügbar gemacht werden kann.

Beispiel

Betrachten Sie als Beispiel ein Datenbankschema mit den Versionen v1 , v2 und v3 und einigen tatsächlichen Datenbanken , die alle eine dieser Versionen des Schemas haben. Für diese Frage sollte die empfohlene Software in der Lage sein, eine bestimmte Datenbank von ihrer aktuellen Version auf eine andere Version desselben Schemas zu aktualisieren (oder herunterzustufen), und sie sollte den Code für eine bestimmte Schemaversion verwenden, die im Versionskontrollsystem gespeichert ist.

Einige in den Kommentaren erwähnte spezifische Kriterien

"Wählen Sie einen Versionskontrolleintrag aus, der ein Schema enthält, und bewerten Sie die DB (neu) entsprechend (was bedeutet das genau?"

Das Datenbankschema wird in einem Versionskontrollsystem als Code dargestellt. Ich bin nicht an Tools interessiert, die direkt mit der Versionskontrolle zusammenarbeiten. Die Tools, zu denen diese Frage Empfehlungen einfordert, sollten in der Lage sein Verwenden Sie eine 'Version' des Datenbankschemas. Ein Beispiel für eine 'Version' des Schemas ist der Code, der das Schema ab einer bestimmten Revision ('Commit' in Git) oder ein bestimmtes Tag / Label für die Versionskontrolle darstellt Systeme, die solche Funktionen unterstützen.

Hier ist eine grundlegende Liste von Funktionen, die für ein Tool bereitgestellt werden sollten, um "die [Ziel-] DB entsprechend (neu) zu bewerten":

Tabellen

  • Wenn im Quellschema eine Tabelle vorhanden ist, jedoch nicht in der Zieldatenbank, sollte das Tool die Tabelle in der Zieldatenbank erstellen. Dies sollte zusätzliche Objekte wie Schlüssel, Einschränkungen, Standardeinstellungen, Indizes, Trigger usw. enthalten.
  • Wenn eine Tabelle im Quellschema nicht vorhanden ist, jedoch in der Zieldatenbank sollte das Tool Mittel bereitstellen, um anzugeben, ob die Tabelle in der Zieldatenbank gelöscht werden soll oder nicht. [Diese Einstellung gilt möglicherweise für alle diese Tabellen.]

Tabellenspalten

  • Wenn eine Spalte in einer Tabelle im Quellschema vorhanden ist, jedoch nicht in der Dieselbe 1 sup> -Tabelle in der Zieldatenbank sollte in der Zieldatenbank erstellt werden. Da die DDL-Anweisungen für die meisten (?) DBMS bereits Möglichkeiten bieten, den Anfangswert neuer Spalten für vorhandene Tabellen anzugeben (z. B. insbesondere für neue Spalten, die keine NULL -Werte zulassen ), Ich bin Agnostiker darüber, ob das Tool selbst etwas Besonderes bereitstellen muss, um damit umzugehen. Wenn jedoch ein empfohlenes Tool eine Form von 'Schemacode' verwendet, die nicht die Standard-DDL-Anweisungen des jeweiligen DBMS 2 sup> sind, sollte das Tool eine Möglichkeit zur Angabe bereitstellen Die Anfangswerte der hinzuzufügenden Spalten.
  • Wenn eine Tabellenspalte nicht im Quellschema vorhanden ist, jedoch in der Zieldatenbank vorhanden ist, wird die Das Tool sollte Mittel bereitstellen, um anzugeben, ob die Spalte in der Zieldatenbank gelöscht werden soll oder nicht. [Diese Einstellung kann für alle diese Tabellenspalten gelten.]
  • Wenn dieselbe Quellenspalte 1 sup> sowohl im Quellschema als auch in den Zieldatenbanken vorhanden ist, diese jedoch unterschiedlichen Typs sind oder andere Unterschiede bestehen (z. B. Länge, numerische Skala usw.), wird die Das Tool sollte die Spalte in der Zieldatenbank so ändern, dass sie mit dem Quellschema übereinstimmt, und sich nach besten Kräften bemühen, die vorhandenen Daten in dieser Spalte beizubehalten. Es ist durchaus gültig, wenn ein empfohlenes Tool den Berichtsfehler beendet, wenn es nicht in der Lage ist, die vorhandenen Daten ohne Verlust zu konvertieren (z. B. wenn die Länge einer Spalte verringert wird und Daten abgeschnitten werden müssten).

Zusatzobjekte zu einer oder mehreren Tabellen

Einige Beispiele für diese Objekte sind Primärschlüssel, Fremdschlüsseleinschränkungen, Standardeinstellungen und Indizes.

  • Wenn ein Zusatzobjekt zu Einige Tabellen sind im Quellschema vorhanden, jedoch nicht in der Zieldatenbank. Sie sollten in der Zieldatenbank erstellt werden. Wie oben sollte das Tool für die Erstellung neuer Tabellenspalten in der Lage sein, Szenarien mit möglichen Konflikten oder Fehlern beim Hinzufügen des Zusatzobjekts zu verarbeiten. Es ist völlig in Ordnung, wenn das Tool es einfach den Personen überlässt, die den Schemacode verwalten, um sicherzustellen, dass Konflikte oder Fehler ordnungsgemäß behandelt werden. Es ist völlig gültig, dass das Tool die Fehlermeldung beendet, wenn ein Konflikt oder ein Fehler wie dieser auftritt.
  • Wenn ein zu einer Tabelle gehörendes Objekt nicht im Quellschema vorhanden ist, jedoch in der Zieldatenbank vorhanden ist, sollte das Tool Mittel zum Angeben bereitstellen, ob Das Zusatzobjekt sollte in der Zieldatenbank abgelegt werden. [Diese Einstellung kann für alle diese Objekte gelten.]
  • Wenn sowohl im Quellschema als auch in der Zieldatenbank dasselbe 1 sup> -Objekt vorhanden ist, sollte sich das Tool ändern (oder löschen und und neu erstellen) das Objekt in der Zieldatenbank so, dass es mit dem Quellschema übereinstimmt.

Andere Objekte

Mit "anderes Objekt" beziehe ich mich auf Objekte wie Ansichten, gespeicherte Prozeduren, benutzerdefinierte Funktionen usw. Diese Objekte können im Allgemeinen (?) sicher gelöscht und neu erstellt werden. Ein empfohlenes Tool sollte in der Lage sein, diese Objekte in der erforderlichen Reihenfolge für Objekte zu löschen und neu zu erstellen, die von anderen solchen Objekten abhängen (z. B. eine Ansicht, die auf eine andere Ansicht verweist).

  • Wenn ein anderes Objekt, usw., die im Quellschema vorhanden sind, jedoch nicht in der Zieldatenbank, sollte in der Zieldatenbank erstellt werden.
  • Wenn ein anderes Objekt wie eine Ansicht, bla bla bla, nicht ist im Quellschema vorhanden, jedoch in der Zieldatenbank. Das Tool sollte eine Möglichkeit bieten, anzugeben, ob das andere Objekt in der Zieldatenbank gelöscht werden soll. [Diese Einstellung kann für alle derartigen anderen Objekte gelten.]
  • Wenn eines dieser Objekte sowohl im Quellschema als auch in der Zieldatenbank vorhanden ist, sollte das Tool das Objekt in der ändern (oder löschen und neu erstellen) Zieldatenbank, die mit dem Quellschema übereinstimmt.

Statische Daten

Zeilen in der Tabelle mit zu synchronisierenden 'statischen' Daten sollten durch die Werte der Spalten in identifiziert werden Primärschlüssel für diese Tabelle.

Zeilen in statischen Datentabellen in der Zieldatenbank sollten an das Quellschema angepasst werden. Zeilen im Quellschema, die sich nicht in der Zieltabelle befinden, sollten in die Zieltabelle eingefügt werden. Es wäre schön, wenn das Tool eine Möglichkeit bieten würde, anzugeben, ob in der Zieltabelle vorhandene Zeilen, die im Quellschema nicht vorhanden sind, gelöscht werden sollen.

Hinweise

1 sup> Dies ist tatsächlich ein potenziell subtiler Punkt! Die meisten Tools implementieren wahrscheinlich "Gleichheit" für Datenbankobjekte wie mit demselben Namen . Es gibt jedoch Alternativen, zumindest für einige DBMS, z. In SQL Server können erweiterte Eigenschaften verwendet werden, um eine Form der persistenten Identität für Datenbankobjekte zu implementieren, die vom Namen des Objekts unabhängig ist. Dies wäre praktisch, da das Tool dann (zumindest einige) Fälle, in denen Objekte umbenannt werden, automatisch verarbeiten kann.

2 sup> Ich habe speziell nach SQL Server gefragt, aber diesbezüglich Ich würde es wirklich lieben, wenn jemand für jedes DBMS überhaupt eine Antwort auf diese Frage geben würde.

Zwei antworten:
#1
+3
Steve Kallestad
2014-02-19 08:09:46 UTC
view on stackexchange narkive permalink

Es stehen Ihnen einige Optionen zur Verfügung.

Liquibase (Free, Apache License) ist die einzige mir bekannte kostenlose Option, die SQL Server unterstützt. Es handelt sich um ein eigenes Versionsverwaltungspaket. Dies bedeutet, dass Sie einen weiteren Befehlssatz erlernen und das Verzweigen, Zusammenführen usw. herausfinden müssen. Der Bonuspunkt für Liquibase ist, dass Sie mit Java-Bibliotheken mithilfe der Liquibase-Bibliotheken Ihre eigene Automatisierung erstellen können

Offscale (kostenlose, nicht spezifizierte Lizenz) geht noch einen Schritt weiter, indem Sie auch Quellcodeverwaltungsdatensätze erstellen und ein bestimmtes Modell mit einem Testdatensatz automatisiert testen können. Leider keine Unterstützung für SQL Server.

Redgate SQL Source Control ist eine nette kommerzielle Option. Es unterstützt SQL Server, Oracle usw. und eine Vielzahl bewährter Versionsverwaltungsplattformen (svn, git, mercurial, perforce usw.). Es unterstützt auch die Datenversionierung. Sie haben ein Begleitprodukt für die kontinuierliche Integration (automatisierte Bereitstellung) und eine Vielzahl anderer Tools im selben Raum. Meiner Meinung nach etwas zu teuer für den persönlichen Gebrauch, aber für den Unternehmensgebrauch sehr günstig. Es gibt eine kostenlose Testversion.

OffScale scheint verschwunden zu sein. Die Website ist nicht nur nicht verfügbar, sondern [der neueste zwischengespeicherte Schnappschuss] (https://web.archive.org/web/20180315061844/http://off-scale.com/) scheint ohnehin das letzte Mal im Jahr 2012 aktualisiert worden zu sein .
#2
+2
Kenny Evitt
2014-02-05 22:17:03 UTC
view on stackexchange narkive permalink

DB Ghost

Übersicht

Die DB Ghost -Produkte erfüllen die Anforderungen.

Das Change Manager-Produkt kann Skripts generieren ( DROP und CREATE -Skripte, die manuell ausgeführt werden können) für alle Schemaobjekte sowie für statische Daten. Das Change Manager Professional-Produkt kann dazu über die Befehlszeile automatisiert werden, z.

Die Produkte Packager, Packager Plus und Packager Plus Professional können Änderungen in Form einer bestimmten Version der von Change Manager erstellten Skripts bereitstellen. Packager Plus kann ein 'dynamisches Upgrade' durchführen, im Grunde ein Schema und eine 'Synchronisation' statischer Daten zwischen einer Zieldatenbank und einer Quellendatenbank, wobei die Quellendatenbank aus Skripten erstellt werden kann. Packager Plus kann auch eine ausführbare Datei erstellen, die verteilt werden kann, um das dynamische Upgrade in der entsprechenden Zielumgebung durchzuführen. Packager Plus Professional kann automatisiert werden, um alle oben genannten Aufgaben über die Befehlszeile auszuführen.

"Synchronisieren" im Vergleich zur Migration

Eine gängige Strategie zum Verwalten von Änderungen an einem Datenbankschema besteht darin, Datenbankmigrationen explizit beizubehalten. sowohl zum Upgraden als auch zum Downgrade. Eine Migration ist effektiv Code für die Durchführung einer einzelnen Änderung an einer Datenbankinstanz eines Schemas.

Sie können Migrationen mit DB Ghost verwalten, erlauben jedoch nur Wenn Sie dies tun, wird es darüber hinaus definitiv nicht unterstützt. Ich denke jedoch, dass dies eine gute Sache ist.

Anstatt Datenbanken während einer Bereitstellung zu migrieren, synchronisiert DB Ghost stattdessen die Zieldatenbank (die Datenbank, für die Sie Änderungen bereitstellen möchten) mit einer Modellquelldatenbank Dies wird während der Bereitstellung aus einer bestimmten Version des Datenbankschemas generiert. Anstatt bestimmte Migrationen auszuführen, werden die Quell- und Zieldatenbanken verglichen und die erforderlichen Änderungen an der Zieldatenbank vorgenommen, um festgestellte Unterschiede zu beheben.

Der Hauptvorteil der Synchronisierung gegenüber der Migration besteht darin, dass anstelle der Verwaltung aller Skripte für alle Migrationen (meistens) Skripts für die aktuelle Version aller Datenbankobjekte im Schema verwaltet werden können . Daher wird der Code, der das Schema darstellt, nach Datenbankobjekten organisiert, anstatt über eine (möglicherweise große) Anzahl von Migrationen verteilt zu sein.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...