Ich möchte das Schema und die „statischen“ Daten einer SQL Server-Datenbank als Code in einem Versionskontrollsystem verwalten. 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 herunterzumigrieren).

Klärung

Datenbanken

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

Datenbankschema als Code

Unter Softwareentwicklern , die mit Datenbanken arbeiten, ist es wünschenswert, das „ Schema “ einer Datenbank, dh Informationen über ihre Struktur, in Form von „ Code “ pflegen 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. B. SQL -Code, typischerweise in einer herstellerspezifischen Version davon, der verwendet wird, um Objekte wie Tabellen und Indizes in einer Datenbank zu erstellen, oder er könnte allgemein sein Programmiersprache , zB Java , Ruby , C#, etc.

Versionskontrolle und Code

Sobald das Schema einer Datenbank in Code dargestellt ist, kann dieser Code in einem Versionskontroll- oder Quellkontrollsystem, einer Software zur Verwaltung der Revisionskontrolle, verwaltet werden. Aus Wikipedia:

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

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

Software-Bereitstellung

' Bereitstellung ' umfasst im Zusammenhang mit Softwareentwicklung und Softwarewartung "... alle Aktivitäten, die ein Softwaresystem für die Nutzung verfügbar machen". Im Rahmen dieser Frage interessieren mich Empfehlungen für Softwaretools, um eine bestimmte Version eines Datenbankschemas in Form konkreter spezifischer Instanzen von Datenbanken im SQL Server DBMS bereitzustellen.

Beispiel

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

Einige spezifische Kriterien, die in den Kommentaren erwähnt werden

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

Das Datenbankschema wird als Code in einem Versionskontrollsystem dargestellt. Ich interessiere mich nicht für Tools, die direkt mit der Versionskontrolle arbeiten. Die Tools, zu denen diese Frage Empfehlungen erbittet, sollten in der Lage sein, eine „Version“ des Datenbankschemas zu verwenden. Ein Beispiel für eine „Version“ eines Schemas wäre der Code, der das Schema ab einer bestimmten Revision darstellt („commit“ in Git) oder ein bestimmtes Tag/Label für Versionskontrollsysteme, die solche Funktionen unterstützen.

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

Tische

• Wenn eine Tabelle im Quellschema, aber nicht in der Zieldatenbank vorhanden ist, sollte das Tool die Tabelle in der Zieldatenbank erstellen. Dies sollte Hilfsobjekte wie Schlüssel, Einschränkungen, Standardwerte, Indizes, Trigger usw. enthalten.
• Wenn eine Tabelle nicht im Quellschema, aber in der Zieldatenbank existiert, sollte das Tool Mittel bereitstellen, um anzugeben, ob die Tabelle in der Zieldatenbank gelöscht werden soll oder nicht. [Diese Einstellung kann für alle diese Tabellen gelten.]

Tabellenspalten

• Wenn eine Spalte in einer Tabelle im Quellschema, aber nicht in derselben Tabelle in der Zieldatenbank vorhanden ^ist , sollte sie 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 NULLWerte zulassen), bin ich mir nicht sicher, ob etwas Besonderes bereitgestellt werden muss durch das Tool selbst, um dies zu handhaben. Wenn jedoch ein empfohlenes Tool irgendeine Form von „Schemacode“ verwendet, der nicht die Standard-DDL-Anweisungen des jeweiligen DBMS ² ist, sollte das Tool Mittel zum Angeben der Anfangswerte von hinzuzufügenden Spalten bereitstellen.
• Wenn eine Tabellenspalte nicht im Quellschema, aber in der Zieldatenbank vorhanden ist, sollte das Tool 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 sowohl im Quellschema als auch in den Zieldatenbanken dieselbe ¹ -Tabellenspalte vorhanden ist, sie jedoch unterschiedlichen Typs sind oder andere Unterschiede bestehen (z. B. Länge, numerische Skalierung usw.), sollte das Tool die Spalte in der Zieldatenbank ändern in mit dem Quellschema übereinstimmen und sich nach besten Kräften bemühen, die vorhandenen Daten in dieser Spalte beizubehalten . Es ist absolut gültig, dass ein empfohlenes Tool den Berichtsfehler beendet, wenn es die vorhandenen Daten nicht ohne Verlust konvertieren kann (z. B. wenn die Länge einer Spalte verringert wird und Daten abgeschnitten werden müssten).

Zu einer Tabelle(n) gehörende Objekte

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

• Wenn ein zu einer Tabelle untergeordnetes Objekt im Quellschema, aber nicht in der Zieldatenbank vorhanden ist, sollte es 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 Hilfsobjekts zu handhaben. 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 zulässig, dass das Tool die Fehlermeldung beendet, wenn es auf einen solchen Konflikt oder Fehler stößt.
• Wenn ein zu einer Tabelle untergeordnetes Objekt nicht im Quellschema, aber in der Zieldatenbank vorhanden ist, sollte das Tool Mittel bereitstellen, mit denen angegeben werden kann, ob das untergeordnete Objekt in der Zieldatenbank gelöscht werden soll. [Diese Einstellung kann für alle diese Objekte gelten.]
• Wenn dasselbe ¹ Objekt sowohl im Quellschema als auch in der Zieldatenbank vorhanden ist, sollte das Tool das Objekt in der Zieldatenbank ändern (oder löschen und neu erstellen), damit 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, die von anderen solchen Objekten abhängen (z. B. eine Ansicht, die auf eine andere Ansicht verweist), zu löschen und neu zu erstellen.

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

Statische Daten

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

Zeilen in statischen Datentabellen in der Zieldatenbank sollten so geändert werden, dass sie mit dem Quellschema übereinstimmen. Zeilen im Quellschema, die nicht in der Zieltabelle enthalten sind, sollten in die Zieltabelle eingefügt werden. Es wäre schön, wenn das Tool eine Möglichkeit bieten würde, anzugeben, ob Zeilen, die in der Zieltabelle vorhanden sind, die im Quellschema nicht vorhanden sind, gelöscht werden sollen.

Anmerkungen

¹ Dies ist tatsächlich ein potenziell subtiler Punkt! Die meisten Tools werden wahrscheinlich 'Sameness' für Datenbankobjekte mit demselben Namen implementieren . Aber es gibt Alternativen, zumindest für einige DBMS, z. B. in SQL Server könnten erweiterte Eigenschaften verwendet werden, um eine Form von persistenter Identität für Datenbankobjekte zu implementieren, die unabhängig vom Namen des Objekts ist. Dies wäre praktisch, da das Tool dann in der Lage wäre, (zumindest einige) Fälle, in denen Objekte umbenannt werden, automatisch zu behandeln.

² Ich habe speziell nach SQL Server gefragt, aber an dieser Stelle würde ich es wirklich lieben, wenn jemand für jedes DBMS überhaupt eine Antwort auf diese Frage geben würde.