Hibernate: hbm2ddl.auto=update in der Produktion?

Question

Ist es in Ordnung, Hibernate-Anwendungen auszuführen, die mit hbm2ddl.auto=update um das Datenbankschema in einer Produktionsumgebung zu aktualisieren?

Answer 1

Es ist nicht sicher und wird nicht empfohlen, aber es ist möglich.

Ich habe Erfahrung mit einer Anwendung, bei der die automatische Aktualisierungsoption in der Produktion verwendet wird.

Die Hauptprobleme und -risiken dieser Lösung sind jedoch folgende:

• Einsatz in der falschen Datenbank . Wenn Sie den Fehler begehen, den Anwendungsserver mit einer alten Version der Anwendung (EAR/WAR/etc) in der falschen Datenbank zu betreiben... Sie werden eine Menge neuer Spalten, Tabellen, Fremdschlüssel und Fehler haben. Das gleiche Problem kann durch einen einfachen Fehler in der Datenquellendatei auftreten (Datei kopieren/einfügen und vergessen, die Datenbank zu ändern). Zusammenfassend lässt sich sagen, dass die Situation in Ihrer Datenbank eine Katastrophe sein kann.
• Anwendungsserver braucht zu lange zum Starten . Dies geschieht, weil Hibernate bei jedem Start der Anwendung versucht, alle erstellten Tabellen/Spalten/etc zu finden. Er muss wissen, was (Tabelle, Spalte, etc.) erstellt werden muss. Dieses Problem wird nur noch schlimmer, wenn die Datenbanktabellen größer werden.
• Datenbank-Tools sind fast unmöglich zu benutzen . Um Datenbank-DDL- oder DML-Skripte zu erstellen, die mit einer neuen Version ausgeführt werden sollen, müssen Sie sich überlegen, was nach dem Start des Anwendungsservers durch die automatische Aktualisierung erstellt werden soll. Wenn Sie beispielsweise eine neue Spalte mit Daten füllen müssen, müssen Sie den Anwendungsserver starten, warten, bis Hibernate die neue Spalte erstellt hat, und das SQL-Skript erst danach ausführen. Wie Sie sehen können, ist es fast unmöglich, Datenbank-Migrations-Tools (wie Flyway, Liquibase, etc.) zu verwenden, wenn die automatische Aktualisierung aktiviert ist.
• Datenbankänderungen sind nicht zentralisiert . Mit der Möglichkeit, mit Hibernate Tabellen und alles andere zu erstellen, ist es schwierig, die Änderungen an der Datenbank in jeder Version der Anwendung zu beobachten, da die meisten automatisch vorgenommen werden.
• Ermutigt zu Müll in der Datenbank . Aufgrund der "einfachen" Verwendung der automatischen Aktualisierung besteht die Möglichkeit, dass Ihr Team alte Spalten und Tabellen vernachlässigt, weil die automatische Aktualisierung im Ruhezustand dies nicht kann.
• Drohende Katastrophe . Das unmittelbare Risiko, dass bei der Produktion eine Katastrophe eintritt (wie in anderen Antworten erwähnt). Selbst wenn eine Anwendung jahrelang läuft und aktualisiert wird, halte ich dies nicht für eine sichere Wahl. Ich habe mich bei der Nutzung dieser Option nie sicher gefühlt.

Ich empfehle daher nicht, die automatische Aktualisierung in der Produktion zu verwenden.

Wenn Sie die automatische Aktualisierung wirklich in der Produktion einsetzen wollen, empfehle ich Ihnen:

• Getrennte Netze . Ihre Testumgebung kann nicht auf die homologe Umgebung zugreifen. Dadurch wird verhindert, dass ein Einsatz, der eigentlich in der Testumgebung stattfinden sollte, die Homologationsdatenbank verändert.
• Skripte verwalten bestellen . Sie müssen Ihre Skripte so organisieren, dass sie vor der Bereitstellung (Änderung der Strukturtabelle, Löschen von Tabellen/Spalten) und nach der Bereitstellung (Ausfüllen von Informationen für die neuen Spalten/Tabellen) ausgeführt werden.

Und, anders als in den anderen Beiträgen, glaube ich nicht, dass die aktivierte automatische Aktualisierung etwas mit den "sehr gut bezahlten" DBAs zu tun hat (wie in anderen Beiträgen erwähnt). DBAs haben Wichtigeres zu tun, als SQL-Anweisungen zum Erstellen/Ändern/Löschen von Tabellen und Spalten zu schreiben. Diese einfachen, alltäglichen Aufgaben können von den Entwicklern erledigt und automatisiert werden und werden nur an das DBA-Team zur Überprüfung weitergegeben, ohne dass Hibernate und die "sehr gut bezahlten" DBAs sie schreiben müssen.

Answer 2

Nein, tun Sie das niemals. Hibernate kann keine Datenmigration durchführen. Ja, es sorgt dafür, dass Ihr Schema korrekt aussieht, aber es stellt nicht sicher, dass wertvolle Produktionsdaten dabei nicht verloren gehen.

Answer 3

• Typischerweise werden Unternehmensanwendungen in großen Organisationen mit eingeschränkten Berechtigungen ausgeführt.

• Der Datenbank-Benutzername darf nicht DDL Privileg zum Hinzufügen von Spalten, die hbm2ddl.auto=update erfordert.

Answer 4

Ich stimme mit Vladimir überein. Die Verwaltungsangestellten in meinem Unternehmen würden es definitiv nicht gutheißen, wenn ich einen solchen Kurs auch nur vorschlagen würde.

Wenn Sie ein SQL-Skript erstellen, anstatt Hibernate blind zu vertrauen, haben Sie außerdem die Möglichkeit, nicht mehr verwendete Felder zu entfernen. Hibernate tut dies nicht.

Und ich finde, dass man durch den Vergleich des Produktionsschemas mit dem neuen Schema noch besser erkennen kann, was man am Datenmodell geändert hat. Man weiß es natürlich, weil man es gemacht hat, aber jetzt sieht man alle Änderungen auf einen Schlag. Sogar die, bei denen man sich fragt: "Was zum Teufel?!".

Es gibt Tools, die ein Schemadelta für Sie erstellen können, so dass es nicht einmal harte Arbeit ist. Und dann wissen Sie genau, was passieren wird.

Answer 5

Die Schemata von Anwendungen können sich im Laufe der Zeit weiterentwickeln. Wenn Sie mehrere Installationen mit unterschiedlichen Versionen haben, sollten Sie über eine Möglichkeit verfügen, um sicherzustellen, dass Ihre Anwendung, ein Tool oder ein Skript in der Lage ist, Schema und Daten von einer Version schrittweise in eine beliebige nachfolgende Version zu migrieren.

Die gesamte Persistenz in Hibernate-Mappings (oder Annotationen) ist eine sehr gute Möglichkeit, die Schemaentwicklung unter Kontrolle zu halten.

Sie sollten bedenken, dass bei der Schemaentwicklung mehrere Aspekte zu berücksichtigen sind:

1. Entwicklung des Datenbankschemas in Hinzufügen weiterer Spalten und Tabellen

2. Löschen von alten Spalten, Tabellen und Beziehungen

3. neue Spalten mit Standardwerten füllen

Hibernate-Tools sind vor allem dann wichtig, wenn Sie (wie in meiner Erfahrung) verschiedene Versionen derselben Anwendung auf vielen verschiedenen Arten von Datenbanken haben.

Punkt 3 ist sehr heikel, wenn Sie Hibernate verwenden, denn wenn Sie eine neue boolesche oder numerische Eigenschaft einführen und Hibernate in solchen Spalten einen Nullwert findet, wird eine Ausnahme ausgelöst.

Also, was ich tun würde, ist: verwenden Sie in der Tat die Hibernate-Tools Kapazität von Schema-Update, aber Sie müssen neben ihm einige Daten und Schema Wartung Callback, wie für das Füllen von Standardwerten, nicht mehr verwendeten Spalten, und ähnliches hinzufügen. Auf diese Weise erhalten Sie die Vorteile (datenbankunabhängige Skripte für die Schemaaktualisierung und Vermeidung doppelter Kodierung der Aktualisierungen in der Peristenz und in den Skripten), decken aber auch alle Aspekte der Operation ab.

Wenn eine Versionsaktualisierung beispielsweise einfach darin besteht, eine varchar-bewertete Eigenschaft (also eine Spalte) hinzuzufügen, die standardmäßig auf null gesetzt werden kann, ist die automatische Aktualisierung abgeschlossen. Wo mehr Komplexität erforderlich ist, ist auch mehr Arbeit nötig.

Dies setzt voraus, dass die Anwendung, wenn sie aktualisiert wird, in der Lage ist, ihr Schema zu aktualisieren (dies ist möglich), was auch bedeutet, dass sie die entsprechenden Benutzerrechte für das Schema haben muss. Wenn die Richtlinien des Kunden dies verhindern (was wahrscheinlich bei Lizard Brain der Fall ist), müssen Sie die datenbankspezifischen Skripte bereitstellen.