Wie verwalten Sie Schema-Upgrades für eine Produktionsdatenbank?

https://stackoverflow.com/questions/29744

09-06-2019
|

Frage

Dies scheint ein übersehener Bereich zu sein, der wirklich einige Erkenntnisse gebrauchen könnte.Was sind Ihre Best Practices für:

Durchführung eines Upgrade-Vorgangs
bei Fehlern einen Rückzieher machen
Synchronisierung von Code- und Datenbankänderungen
Tests vor der Bereitstellung
Mechanik der Tischmodifikation

usw...

Lösung

Das ist eine tolle Frage.(Es besteht eine hohe Wahrscheinlichkeit, dass dies zu einer Debatte zwischen normalisierten und denormalisierten Datenbanken führt, mit der ich nicht beginnen werde ...Okay, jetzt für etwas Input.)

einige spontane Dinge, die ich getan habe (ich werde weitere hinzufügen, wenn ich etwas mehr Zeit habe oder eine Pause brauche)

Client-Design – hier bringt Sie die VB-Methode von Inline-SQL (auch mit vorbereiteten Anweisungen) in Schwierigkeiten.Sie können ewig damit verbringen, diese Aussagen zu finden.Wenn Sie so etwas wie Hibernate verwenden und so viel SQL in benannte Abfragen einfügen, haben Sie einen einzigen Ort für den Großteil des SQL (nichts ist schlimmer, als zu versuchen, SQL zu testen, das sich in einer IF-Anweisung befindet, und Sie drücken einfach nicht den „Auslöser“). Kriterien in Ihrem Test für diese IF-Anweisung berücksichtigen).Vor der Verwendung von Hibernate (oder anderen Orms), wenn ich SQL direkt in JDBC oder ODBC ausführen würde, habe ich alle SQL-Anweisungen entweder als öffentliche Felder eines Objekts (mit einer Namenskonvention) oder in einer Eigenschaftendatei (ebenfalls mit einer Benennung) abgelegt Konvention für die Werte lautet PREP_STMT_xxxx.Und verwenden Sie entweder Reflektion oder iterieren Sie über die Werte beim Start in a) Testfällen b) Start der Anwendung (einige RDBMS erlauben Ihnen, vor der Ausführung vorbereitete Anweisungen vorzukompilieren, also würde ich beim Start nach der Anmeldung die Vorbereitung vorkompilieren). stmts beim Start, damit die Anwendung einen Selbsttest durchführt.Selbst für Hunderte von Anweisungen auf einem guten RDBMS sind das nur ein paar Sekunden.und nur einmal.Und es hat meinen Hintern sehr gerettet.Bei einem Projekt kommunizierten die DBAs nicht (ein anderes Team, in einem anderen Land) und das Schema schien sich NACHTLICH zu ändern, ohne Grund.Und jeden Morgen erhielten wir eine Liste mit der genauen Angabe, wo die Anwendung beim Start kaputt gegangen ist.

Wenn Sie Ad-hoc-Funktionalität benötigen, fügen Sie sie in eine gut benannte Klasse ein (z. B.Auch hier hilft eine Namenskonvention beim automatischen Testen), die als eine Art Fabrik für Ihre Abfrage fungiert (d. h.es erstellt die Abfrage).Sie müssen sowieso den entsprechenden Code schreiben. Platzieren Sie ihn einfach an einem Ort, an dem Sie ihn testen können.Sie können sogar einige grundlegende Testmethoden für dasselbe Objekt oder in einer separaten Klasse schreiben.

Wenn möglich, versuchen Sie auch, gespeicherte Prozeduren zu verwenden.Sie sind etwas schwieriger zu testen als oben.Einige Datenbanken validieren die SQL in gespeicherten Prozessen auch nicht vorab anhand des Schemas zur Kompilierungszeit, sondern nur zur Laufzeit.Normalerweise geht es darum, beispielsweise eine Kopie der Schemastruktur (keine Daten) zu erstellen und dann alle gespeicherten Prozesse anhand dieser Kopie zu erstellen (für den Fall, dass das Datenbankteam, das die Änderungen vornimmt, die Validierung nicht korrekt durchgeführt hat).Somit kann die Struktur überprüft werden.Aber als Punkt des Änderungsmanagements sind gespeicherte Prozesse großartig.Beim Wechsel bekommen es alle.Insbesondere wenn die Datenbankänderungen das Ergebnis von Geschäftsprozessänderungen sind.Und alle Sprachen (Java, VB usw. erhalten die Änderung)

Normalerweise richte ich auch eine von mir verwendete Tabelle mit dem Namen system_setting usw. ein.In dieser Tabelle behalten wir eine VERSION-Kennung bei.Auf diese Weise können Clientbibliotheken eine Verbindung herstellen und überprüfen, ob sie für diese Version des Schemas gültig sind.Abhängig von den Änderungen an Ihrem Schema möchten Sie nicht zulassen, dass Clients eine Verbindung herstellen, wenn sie Ihr Schema beschädigen können (z. B.Sie haben nicht viele referenzielle Regeln in der Datenbank, sondern auf dem Client.Es hängt davon ab, ob Sie auch mehrere Client-Versionen haben werden (was bei NICHT-Web-Apps der Fall ist, d. h.sie führen die falsche Binärdatei aus).Sie könnten auch Batch-Tools usw. haben.Ein anderer Ansatz, den ich ebenfalls durchgeführt habe, besteht darin, einen Satz Schemas für Betriebsversionen in einer Art Eigenschaftendatei oder wiederum in einer system_info-Tabelle zu definieren.Diese Tabelle wird bei der Anmeldung geladen und dann von jedem „Manager“ (ich habe normalerweise eine Art clientseitige API für die meisten Datenbankaufgaben) verwendet, um für diesen Vorgang zu überprüfen, ob es sich um die richtige Version handelt.Daher können die meisten Vorgänge erfolgreich sein, aber Sie können bei veralteten Methoden auch fehlschlagen (eine Ausnahme auslösen) und Ihnen sagen, WARUM.

Verwaltung der Schemaänderung -> Aktualisieren Sie die Tabelle oder fügen Sie 1-1-Beziehungen zu neuen Tabellen hinzu?Ich habe viele Shops gesehen, die aus diesem Grund immer über eine Ansicht auf Daten zugreifen.Dadurch können Tabellennamen, Spalten usw. geändert werden.Ich habe mit der Idee gespielt, Ansichten tatsächlich wie Schnittstellen in COM zu behandeln.dh.Sie fügen eine neue VIEW für neue Funktionen/Versionen hinzu.Was Sie hierher bringt, ist oft, dass Sie viele Berichte (insbesondere benutzerdefinierte Endbenutzerberichte) haben können, die Tabellenformate annehmen.Mit den Ansichten können Sie ein neues Tabellenformat bereitstellen, unterstützen aber vorhandene Client-Apps (denken Sie an all die lästigen Ad-hoc-Berichte).

Außerdem müssen Update- und Rollback-Skripte geschrieben werden.und wieder TESTEN, TESTEN, TESTEN...

------------ OKAY - DAS IST EIN BISSCHEN ZUFÄLLIGE DISKUSSIONSZEIT --------------

Eigentlich hatte ich ein großes kommerzielles Projekt (d. h.(Software-Shop), wo wir das gleiche Problem hatten.Die Architektur war zweistufig und es wurde ein Produkt verwendet, das ein bisschen PHP ähnelte, aber vor PHP war.Gleiche Sache.anderer Name.Jedenfalls bin ich in Version 2 reingekommen....

Die Durchführung von Upgrades hat eine Menge Geld gekostet.Eine Menge.dh.Verschenken Sie wochenlange kostenlose Beratungszeit vor Ort.

Und es kam zu dem Punkt, dass ich entweder neue Funktionen hinzufügen oder den Code optimieren wollte.Einige der vorhandenen Codes verwendeten gespeicherte Prozeduren, sodass wir gemeinsame Punkte hatten, an denen wir Code verwalten konnten.Aber auch in anderen Bereichen wurde dieses SQL-Markup in HTML eingebettet.Das war großartig, um schnell auf den Markt zu kommen, aber mit jedem Zusammenspiel neuer Funktionen verdoppelten sich die Kosten für Test und Wartung mindestens.Als wir uns also mit dem Herausziehen des PHP-Typcodes, dem Einfügen von Datenebenen (das war 2001-2002, vor ORMs usw.) und dem Hinzufügen vieler neuer Funktionen (Kundenfeedback) befassten, befassten wir uns mit dieser Frage, wie man UPGRADES entwickelt in das System ein.Das ist eine große Sache, da die korrekte Durchführung von Upgrades viel Geld kostet.Nun, die meisten Muster und all die anderen Dinge, über die die Leute mit einiger Energie diskutieren, befassen sich mit dem laufenden OO-Code, aber was ist mit der Tatsache, dass Ihre Daten a) in diese Logik integriert werden müssen, b) die Bedeutung und auch die Struktur davon Die Daten können sich im Laufe der Zeit ändern, und oft kommt es aufgrund der Art und Weise, wie Daten funktionieren, zu vielen Unterprozessen/Anwendungen in der Organisation Ihres Kunden, die diese Daten benötigen -> Ad-hoc-Berichte oder komplexe benutzerdefinierte Berichte sowie Batch-Jobs die für benutzerdefinierte Datenfeeds usw. durchgeführt wurden.

Mit diesem Gedanken im Hinterkopf begann ich mit etwas etwas links vom Spielfeld zu spielen.Es gibt auch einige Annahmen.a) Daten werden häufiger gelesen als geschrieben.b) Aktualisierungen finden statt, jedoch nicht auf Bankebene, d. h.ein oder zwei pro Sekunde.

Die Idee bestand darin, eine COM-/Schnittstellenansicht darauf anzuwenden, wie Clients über eine Reihe von CONCRETE-Tabellen auf Daten zugreifen (die je nach Schemaänderungen variierten).Sie können für jeden Typvorgang eine separate Ansicht erstellen – Aktualisieren, Löschen, Einfügen und Lesen.Das ist wichtig.Die Ansichten würden entweder direkt einer Tabelle zugeordnet oder ermöglichen Ihnen das Auslösen einer Dummy-Tabelle, die die eigentlichen Aktualisierungen oder Einfügungen usw. durchführt.Was ich eigentlich wollte, war eine Art abfangbare Level-Indirektion, die weiterhin von Crystal Reports usw. verwendet werden konnte.HINWEIS – Für Einfügungen, Aktualisierungen und Löschungen können Sie auch gespeicherte Prozesse verwenden.Und Sie hatten für jede Version des Produkts eine Version.Auf diese Weise hatte Ihre Version 1.0 ihre Version des Schemas, und wenn sich die Tabellen änderten, hätten Sie immer noch die VIEWS der Version 1.0, aber mit NEUER Backend-Logik, um sie bei Bedarf den neuen Tabellen zuzuordnen, aber Sie hatten auch Ansichten der Version 2.0, die unterstützt würden neue Felder usw.Dies diente eigentlich nur dazu, die Ad-hoc-Berichterstattung zu unterstützen, was, wenn Sie ein GESCHÄFTSmensch und kein Programmierer sind, wahrscheinlich der eigentliche Grund dafür ist, warum Sie das Produkt haben.(Ihr Produkt kann schlecht sein, aber wenn Sie die beste Berichterstattung der Welt haben, können Sie immer noch gewinnen. Das Gegenteil ist der Fall – Ihr Produkt kann hinsichtlich der Funktionen das beste sein, aber wenn die Berichterstattung die schlechteste ist, können Sie sehr leicht verlieren.)

Okay, ich hoffe, einige dieser Ideen helfen.

Andere Tipps

Flüssigkeitsbasis

liquibase.org:

Es versteht Hibernate-Definitionen.
Es generiert eine bessere Schemaaktualisierungs-SQL als der Ruhezustand
Es protokolliert, welche Upgrades an einer Datenbank durchgeführt wurden
Es verarbeitet zweistufige Änderungen (d. h.eine Spalte „foo“ löschen und dann eine andere Spalte in „foo“ umbenennen)
Es behandelt das Konzept bedingter Upgrades
Der Entwickler hört tatsächlich auf die Community (mit Hibernate werden Sie im Grunde ignoriert, wenn Sie nicht zu den „In“-Leuten gehören oder ein Neuling sind).

http://www.liquibase.org

Meinung

Die Anwendung sollte niemals eine Schemaaktualisierung durchführen.Das ist eine Katastrophe, die nur darauf wartet, passiert zu werden.Daten überdauern die Anwendungen und sobald mehrere Anwendungen versuchen, mit denselben Daten zu arbeiten (z. B. die Produktions-App + eine Berichts-App), werden beide wahrscheinlich dieselben zugrunde liegenden Unternehmensbibliotheken verwenden ...und dann beschließen beide Programme, ihr eigenes Datenbank-Upgrade durchzuführen ...viel Spaß mit Das Durcheinander.

Ich bin ein großer Fan von Rotes Tor Produkte, die beim Erstellen von SQL-Paketen zum Aktualisieren von Datenbankschemata helfen.Die Datenbankskripte können zur Quellcodeverwaltung hinzugefügt werden, um bei der Versionierung und dem Rollback zu helfen.

Im Allgemeinen lautet meine Regel:„Die Anwendung sollte ihr eigenes Schema verwalten.“

Dies bedeutet, dass Schema-Upgrade-Skripts Teil jedes Upgrade-Pakets für die Anwendung sind und automatisch ausgeführt werden, wenn die Anwendung gestartet wird.Bei Fehlern kann die Anwendung nicht gestartet werden und die Transaktion des Upgrade-Skripts wird nicht festgeschrieben.Der Nachteil dabei ist, dass die Anwendung vollständigen Änderungszugriff auf das Schema haben muss (das nervt Datenbankadministratoren).

Ich habe mit der SchemaUpdate-Funktion von Hibernates großen Erfolg gehabt, um die Tabellenstrukturen zu verwalten.Den Upgrade-Skripten bleibt nur die tatsächliche Dateninitialisierung und das gelegentliche Entfernen von Spalten vorbehalten (SchemaUpdate übernimmt dies nicht).

Da die Upgrades Teil der Anwendung sind, wird das Testen zu einem Teil des Testzyklus für die Anwendung.

Nachträglicher Gedanke:Beachten Sie, dass die Regel in Anlehnung an die Kritik in anderen Beiträgen hier „ihr Eigenes“ lautet.Es gilt eigentlich nur dort, wo die Anwendung erfolgt besitzt das Schema, wie es im Allgemeinen bei Software, die als Produkt verkauft wird, der Fall ist.Wenn Ihre Software eine Datenbank mit anderer Software teilt, verwenden Sie andere Methoden.

Das sind alles gewichtige Themen, aber hier ist meine Empfehlung zur Aktualisierung.

Sie haben Ihre Plattform nicht angegeben, aber für NANT-Build-Umgebungen verwende ich Tarantino.Für jede Datenbankaktualisierung, die Sie festschreiben möchten, erstellen Sie ein Änderungsskript (mit RedGate oder einem anderen Tool).Wenn Sie die Produktion in die Produktion umwandeln, prüft Tarantino, ob das Skript in der Datenbank ausgeführt wurde (es fügt Ihrer Datenbank eine Tabelle hinzu, um den Überblick zu behalten).Wenn nicht, wird das Skript ausgeführt.Es erfordert die gesamte manuelle Arbeit (lesen Sie:menschliches Versagen) bei der Verwaltung von Datenbankversionen.

Ich habe Gutes darüber gehört iBATIS 3 Schema-Migrationssystem:

Benutzerhandbuch: http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/doc/en/iBATIS-3-Migrations.pdf

Wie Pat sagte, verwenden Sie Liquibase.Vor allem, wenn Sie mehrere Entwickler mit eigenen Entwicklerdatenbanken haben, die Änderungen vornehmen, die Teil der Produktionsdatenbank werden.

Wenn es nur einen Entwickler gibt, wie bei einem Projekt, an dem ich gerade arbeite (ha), schreibe ich die Schemaänderungen einfach als SQL-Textdateien in ein CVS-Repository, das ich stapelweise auf dem Produktionsserver auschecke, wenn die Codeänderungen eingehen .

Aber Liquibase ist besser organisiert!

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow