Versionsverwaltung für SQL Datenbank
-
Hi,
ich möchte gerne eine Versionsverwaltung für meine SQL-Datenbank einrichten. Im Idealfall sollte das so aussehen, dass man auf der Programoberfläche auswählen kann, welche Version man haben möchte und die Daten aus eben dieser verwendet werden. Dabei muss aber ein anderer Nutzer parallel auch eine andere Version verwenden können.
Hat jemand dazu eine Idee? Eine Möglichkeit wäre natürlich, für neue Versionen die einzelnen Tabellen zu kopieren und über eine Versions-Tabelle mit einem Versionstitel zu verknüpfen. Aber geht das auch einfacher?Ich verwende übrigens den MS SQL Server.
-
Ein sehr schönes Thema, eines meiner liebsten sogar. Es gibt für dein Vorhaben verschiedene Wege, je nach Anforderungsprofil.
Wenn wir davon ausgehen, dass die alten Versionen schreibgeschützt sind, könntest du mit Snapshots arbeiten. Auf diese hast du sofort Zugriff, allerdings bist du damit recht eingeschränkt.
Wenn du mehr Flexibilität brauchst, könntest du ein Sicherungssystem programmieren, welches durchgehend alle Transaction Logs speichert. Dadurch wärst du in der Lage, automatisch jeden Zustand der Datenbank wiederherzustellen. Wenn du es entsprechend programmierst, könntest du On The Fly einen Restore an ein bestimmtes Datum fahren und diesen in einer eigenen Datenbank auf dem Server ablegen.
Bedingt durch die Natur dieses Systems kann es aber einige Zeit dauern, bis die alte Version für den Benutzer verfügbar ist. Diese Wartezeit, welche im Extremfall einige Stunden betragen kann, könntest du mit der Verwendung von Differential Backups verkürzen.
-
Heimelchen schrieb:
Dabei muss aber ein anderer Nutzer parallel auch eine andere Version verwenden können.
Nee @/rant/, er will verschiedene Versionsstände gleichzeitig über mehrere Verbindungen lesen, nicht zu einem älterem Zeitpunkt zurückfahren. Wenn er dann neue Daten eingeben würde wären die alten Daten verwaist die nach dem Wiederherstellungspunkt liegen.
@OP: Beantworte am Besten erst mal seine Frage ob du durch die alten Versionen schreiben willst und wozu du in diesem Fall dieses bräuchtest.
-
Ich habe auch nicht gemeint, dass er einen permanenten Restore fährt und die eigentliche Datenbank verliert, sondern dass er ein System programmiert, welches die Möglichkeiten für Restores dahingehend nutzt, und eine alte Version im Verborgenen temporär wiederherstellt.
Der User kommt und sagt, dass er gerne die Datenbank X in der Version mit Datum Y anschauen würde. Das System restored diesen Zustand in eine separate Datenbank in einer schreibgeschützten Filegroup. Der User bekommt davon natürlich nichts mit und arbeitet mit dieser Version wie gewohnt. Irgendwann nachdem er fertig ist, wird diese Version wieder gelöscht.
Um dieses System performant zu bauen, braucht man einen Haufen Differential Backups und schnelle Festplatten; dann kann man innerhalb kurzer Zeit ein paar GB restoren.
Wie gross ist die Datenbank?
-
Die Datenbank ist "noch" recht klein, ca. 6 MB, kann aber auch größer werden. Sie liegt im Intranet.
Das Restore-Prinzip könnte schwierig werden, da es tatsächlich sein könnte, dass mehrere Leute gleichzeitig auf verschiedene Versionen zugreifen. Diese Datenbank verwaltet Produkteigenschaften, werden ältere Produktversionen geändert, müsste auch die Datenbank zu dieser Produktversion geändert werden.
Wenn die Datenbank sowas slebst tut, wär das natürlich der Hit. Zur Not würde ich halt für jede neue Version alle Tabellen der Datenbank kopieren und irgendwo die zu einer Version gehörenden Tabellen auflisten...