Wie gehen Sie mit sich ständig ändernden Datenbankdimensionen um?

9

In den letzten zwei Monaten habe ich nach Lösungen oder Methoden für das Release-Management in Datenbanken gesucht. Ich suche nach dem, was die Leute als den besten Prozess ansehen, um damit umzugehen.

Wir haben 3 Umgebungen für unsere Datenbanken:

Entwicklung
User Acceptance Testing (UAT)
Produktion

Das Problem ist, dass wir manchmal Änderungen an verschiedenen Dingen in unserer Entwicklungsdatenbank vornehmen und es Zeit für die Bereitstellung ist. Einige der Funktionen können möglicherweise nicht für UAT freigegeben werden.

Vor kurzem haben wir begonnen, die Red Gate SQL-Quellcodeverwaltung zum Speichern aller unserer Entitäten (mit regelmäßigen Festschreibungen) zu verwenden.

Ich habe darüber nachgedacht, auf Änderungssätzen zu basieren (dh, alles von Änderungssatz X und zurück wird jetzt an UAT übertragen). Dies bedeutet jedoch, dass die Benutzer ihren Code nur kurz vor der Bereitstellung in die Quellcodeverwaltung einchecken, was verwirrend werden kann ( zumal die Leute vergesslich sind). Ein weiteres Problem bei der Verwendung des Änderungssatzansatzes besteht darin, dass bei einem Fehler in einer gespeicherten Prozedur, der behoben werden muss, die Änderungssatznummer außerhalb des Bereichs unseres maximalen Änderungssatzes für die Revision liegt, sodass dies bei Bedarf der Fall ist Erstellen Sie die Datenbank aus einem maximalen Änderungssatz neu, wir würden den Fehler wieder beseitigen.

Irgendwelche Vorschläge zu einem Prozess?

Vielen Dank

— Judda
quelle

Es hört sich so an, als ob sich Ihre Datenbankskripte nicht in derselben Quellcodeverwaltung befinden wie Ihr "tatsächlicher" Code. Warum ist das? Können Sie es als "Quellcode" behandeln und mit den einzelnen Zweigen versehen?

— Mike M.

Wir speichern derzeit nur die Entwicklungsversion der Skripte in der Quellcodeverwaltung, und UAT / Production sind nicht mit der aktiven Entwicklung synchron. Jedes der Skripte in der Quellcodeverwaltung wird jedes Mal aktualisiert, wenn ein Entwickler ein Commit ausführt. Das Problem mit einzelnen Zweigen ist, dass wir eine zentralisierte Datenbank haben, die jeder verwendet (für größere Änderungen verzweigen wir die separaten Datenbanken).

1

Sie können einen Zweig für das Release erstellen und nur Änderungen daran festschreiben, die sich auf das Release beziehen. Alle anderen Änderungen sollten am Kofferraum vorgenommen werden. Dazu benötigen Sie zwei Entwicklungsdatenbanken. Wäre das ein Problem?

Das klingt so, als würde man wahrscheinlich ziemlich schnell veraltet sein. Nein? Bei einem meiner Projekte befinden wir uns mitten in einer umfassenden Überarbeitung der Datenbank. Daher haben wir diese verzweigt, damit die aktive Entwicklung in der unveränderten Version der Datenbank weiterhin stattfinden kann. Jeden Tag sehe ich jedoch, dass unsere verzweigte Version immer veralteter wird, und ich bin mir nicht sicher, ob das in Ordnung ist oder nicht ... Ich musste mich noch nie wirklich mit solchen Situationen auseinandersetzen.

— Judda

5

Migrationen

Ein Auf und Ab, die in Ihrem Repo sind und zusammen mit Ihrer App markiert sind.

Sie können sogar mit SQL-Flatfiles basteln, die Ihr Schema ändern und die Schemaversion aktualisieren. Alles was Sie wirklich tun müssen ist:

Behalten Sie Ihre Migrationen neben dem Quellcode, sie sollten versioniert und zusammen markiert werden
Verwenden Sie verwaltete Änderungen (Migrationen) immer in allen Umgebungen
Lassen Sie niemals Ad-hoc-Änderungen in Umgebungen zu

Nun, Sie können Entwicklungsänderungen in dev vornehmen, aber Sie sollten Ihre Datenbank immer wegblasen und sie mit Migrationen neu erstellen, sobald Sie die Änderung erfasst haben.

— Dietbuddha
quelle

Was würde passieren, wenn ein Fehler in den Skripten gefunden würde? Gehen Sie zurück zum SQL-Skript und aktualisieren Sie es?

— Judda

1

Nein, Sie erstellen eine neue Migration (wodurch die Schemaversion erhöht wird). Auf diese Weise wissen Sie, dass der Fix bereitgestellt wurde, indem Sie sich die Schemaversion in der Datenbank ansehen.

— Dietbuddha

Danke für Ihre Hilfe. Auf den ersten Blick scheint dies ein sehr solider Ansatz zu sein, der unserer Verzweigungsstrategie ähnelt.

— Judda

2

Quellcodeverwaltung!

Sie stellen Ihre Entwicklungsbinärdateien nicht direkt in der Produktion bereit, ohne über svn / git / p4 zu gehen. Warum sollten Ihre Datenbanken dies allein tun? Holen Sie sich private Instanzen für Entwickler, um ihre lokalen Änderungen zu testen. Wenn sie jedoch zur Entwicklungsdatenbank gehen müssen, müssen sie über die eingecheckten DDL-Dateien erfolgen. Sie können sogar Tools schreiben, um diese ddl-Änderungen automatisch anzuwenden (ich kenne keine Möglichkeit, dies korrekt zu tun).

Sobald Sie die Einschränkungen bezüglich Änderungen des Datenbankschemas haben (kein sqlplus mehr -> ddl ausgeben!) Und eine strikte Kontokontrolle haben (kein ddl-Zugriff auf alle), sollte dies leichter zu handhaben sein.

— Subu Sankara Subramanian
quelle

1

Leider sind unsere Datenbanken zu groß, um zwischen Entwicklern weitergegeben zu werden, damit die privaten Sitzungen ausgeführt werden können. Außerdem scheint das nicht wirklich zu einer teambasierten Entwicklung zu tendieren, da ich ab sofort Back-End-Entwicklung mache, während ich mit den Leuten für die UI-Arbeit spreche, die die beiden verbindet. Ich müsste zunächst alle Änderungen einchecken und sie dann auf den neuesten Stand der Datenbank bringen, was ein ziemlich großer Aufwand zu sein scheint.

— Judda

Warum muss Ihre Entwicklungsdatenbank dieselbe Größe haben wie die Produktionsdatenbank? Sie können dasselbe Schema haben, und Sie können sogar eine spezielle Lasttestflotte mit allen Daten haben, aber die lokalen Entwicklungsdatenbanken können klein sein. Dies verhindert auch die Bedenken hinsichtlich Datenlecks usw. - theoretisch sollten Produktdaten die Entwicklung überhaupt nicht beeinträchtigen.

— Subu Sankara Subramanian

Alle unsere Daten werden durch unseren Datenladeprozess geladen, der die vom Client bereitgestellten Dateien verarbeitet und sie dann in die von uns benötigten Daten umwandelt. Daher ist es für uns unmöglich, die Entwicklungs- und Produktdaten zu trennen, da alle Datenladungen ohnehin in der Entwicklung überprüft werden müssen. Ich denke, es muss nicht dieselbe Größe haben, es benötigt jedoch vergleichbare Datenmengen, damit die von uns erstellten Berichte aussagekräftige Informationen generieren.

— Judda

Die gesamte Datenbank muss nicht repliziert werden. In Oracle hat jeder Benutzer sein eigenes Schema und wir haben ein Anwendungsschema. Erstellen Sie öffentliche Synonyme für alle Objekte im Anwendungsschema. Dann kann jeder Benutzer die Objekte (Tabellen, SPs) in seinem eigenen Schema ändern, und wenn sie sich selbst verbinden, werden ihre Objektnamen verwendet. Für Objekte, die nicht im Schema enthalten sind, werden die Synonyme verwendet. So arbeiten wir.

— Softveda

0

Dem Vorschlag folgen, Migrationen zu verwenden ... Verwenden Sie möglicherweise ein O / RM, das Migrationen wie Ruby on Rails und Entity Framework 4.3 unterstützt. Das Problem bei beiden Ansätzen ist jedoch, dass eine Migration alles oder nichts ist. Sie können (normalerweise) nicht auswählen, welche Migrationen in Bezug auf Änderungssätze angewendet werden sollen.

Eine weitere praktikable Option (wenn Sie sich auf dem Microsoft-Stack befinden und die Plattform nie erwähnt haben) ist die Verwaltung Ihres SQL mit den Visual Studio-Datenbanktools. Es hat ein Refactoring eingebaut (Spalten umbenennen / entfernen usw.) und überprüft das Modell. Wenn ein gespeicherter Prozess beispielsweise auf eine Spalte verweist, die nicht mehr vorhanden ist, werden Sie darüber informiert.

— Michael Brown
quelle