Single version of Truth

Bei der Arbeit mit SQL-Basierten Datenbanken gibt es zwei grundsätzliche Quellen für Schemaänderungen:

Neuanlage einer Datenbank (CREATE DATABASE)
Verändern/Migrieren der Datenbankstruktur (ALTER TABLE, ALTER COLUMN usw.)

Das Verändern der Datenbankstruktur erfolgt über SQL-Skripte. Diese SQL Skripte können:

Views, Tabellen und Spalten anlegen, umbenennen und entfernen.
Typen, Default-Werte, Nullabilities und Auto-Increments und Dimensionen von Spalten ändern (manchmal auch Regeln und Trigger).
Werte in der Datenbank ändern (zum Beispiel um nicht-null-werte zu korrigieren oder foreign-keys zu entsprechen)

Alle diese SQL-Skripte können auch fehlschlagen. Selbst wenn zwei Datenbanken die selbe Datenbankstruktur haben kann bei einer Datenbank die Migration funktionieren und bei der anderen Datenbank fehlschlagen.

Also wurden Tools geschaffen die sich um die Migration kümmern.

Warum nicht Liquibase:diff?

Liquibase:diff erstellt brauchbare Skripte zur Migration. Diese Skripte werden oft mit GIT oder SVN versioniert. Die Neuanlage von Datenbanken sind daher direkt aus den Projektquellen möglich, das ist etwas gutes. Bei Start der Applikation spielt Liquibase die Änderungen ein, die noch nicht eingetragen sind. Dabei gibt es jedoch auch ein paar Kritiken:

Der Start der Applikation wird verzögert weil Liquibase die Datenbank gegen die Entities prüft obwohl das Persistenzframework das auch macht.
Das erstellen der Liquibaseskripte belastet die Datenbank.
Liquibase benötigt zusätzliche Tabellen um herauszufinden welche Skripte schon ausgeführt wurden, das bläht die Datenbank auf.
Die ganze Applikation wird leicht aufgebläht und abhängig gemacht von Liquibase als Komponente, Liquibase nimmt also (über den Start hinaus) Speicher weg.
Liquibase kann fehlschlagen wenn ein SQL-Skript fehlschlägt, das Deployment schlägt also sehr spät fehl. Das passiert in der Regel wenn: das Schema passt aber der Datenbankinhalt nicht. Das Passiert auch wenn der Datenbankserver nicht genug Arbeitsspeicher für die Datenbankänderung hat.
Wer liquibase-skripte in GIT/SVN einpflegt hat in einer GIT/SVN-Revision alle historischen Datenbankänderungen, in jeder je-existierten Version, selbst die überholten, selbst die ausgebauten. Wir haben also eine zweite Versionsdimension innerhalb der GIT/SVN-Revision: Die SQL-Versionen. Damit sind wir gezwungen alle Datenbankversionen die je existiert haben in einem GIT/SVN-Checkout mitzunehmen.
Konflikte bei Datenbankänderungskripen sind manuelle Merge-Arbeit.
Widersprüche in Datenbankänderungsskripten werden, in aller Regel, nicht bemerkt (zwei Personen fügen die selbe Spalte mit unterschiedlichen Namen ein).
Es gibt für den Liquibase-Prozess keine GUI.
Native Liuqibase-Changesets sind nicht Datenbankherstellerübergreifend.
Wenn man sich für Hibernate-Plugins entscheidet (wie Enver oder Audit) werden zusätzliche Anpassungen an Liuqibase nötig.

Wie macht das Release-Manager (RM)?

Die Datenbankentities kommen immer aktuell von Release-Manager als dynamisches Maven-Artefakt. Das ist alles! Das ist einfach.

Dadurch ist man von Migrationsskripten befreit, muss also nicht mergen. Man braucht kein Framework in der App. Man braucht keine zusätzlichen Tabellen. Man braucht zum Bauen keine Datenbankverbindung. Es gibt grundsätzlich keine Widersprüche zwischen Entities und Datenbank. Datenbanken anderer Datenbankhersteller werden als Artefaktversion angegeben und es müssen keine Liquibase-Skripte umgeschrieben werden.

Liquibase	Release-Manager
Start wird verzögert	Start wird nicht verzögert
Erstellen der Liquibase-Skripte belastet die Datenbank	Datenbank wird nicht belastet
Liquibase benötigt zusätzliche Tabellen	Keine zusätzlichen Tabellen werden benötigt
Die Applikation hat Liquibase als Komponente	Die Applikation hat keine zusätzliche Komponente
Liquibase kann zur Laufzeit fehlschlagen	Release-Manager hält sich aus der Laufzeit raus
Liquibase belastet die Versionsverwaltung	Release-Manager hält sich aus der Versionsverwaltung raus
Konflikte bei Liquibase-Skripten sind möglich	Mit Release-Manager gibt es keine derartigen Konflikte. Nur die konkrete Wahrheit.
Widersprüche in den Skripten werden nicht bemerkt	Widersprüche sind möglich, entstehen aber dort wo sie auffallen: An der konkreten Datenbankstruktur.
Es gibt keine Liquibase-GUI	Der Release-Manager hat eine Weboberfläche.
Liquibase muss an Plug-Ins angepasst werden	Der Release-Manager benötigt keine Anpassungen.

When working with SQL-based databases, there are two basic sources of schema changes:

Creating a new database (CREATE DATABASE)
Changing/migrating the database structure (ALTER TABLE, ALTER COLUMN etc.)

Changing the database structure is done by SQL scripts. These SQL scripts can:

Create, rename and remove views, tables and columns.
Change types, default values, nullabilities and auto-increments and dimensions of columns (sometimes also rules and triggers).
Change values in the database (for example to correct non-null values or to match foreign-keys).

All these SQL scripts can also fail. Even if two databases have the same database structure, migration can work on one database and fail on the other.

So tools were created to take care of the migration.

Why not Liquibase:diff?

Liquibase:diff creates usable scripts for migration. These scripts are often versioned with GIT or SVN. New databases can therefore be created directly from the project sources, which is something good. When the application is started, Liquibase will import the changes that have not yet been entered. However, there are a few criticisms:

The start of the application is delayed because Liquibase checks the database against the entities although the persistence framework does the same.
The creation of the Liquibase scripts puts a load on the database.
Liquibase needs additional tables to find out which scripts have already been executed, this bloats the database.
The whole application is slightly bloated and made dependent on Liquibase as a component, so Liquibase takes memory (beyond startup).
Liquibase can fail if a SQL script fails, so the deployment fails very late. This usually happens when: the schema fits but the database content does not. It also happens if the database server does not have enough memory for the database change.
If you put liquibase scripts into GIT/SVN, you have in a GIT/SVN revision all historical database changes, in each ever-existing version, even the outdated ones, even the upgraded ones. So we have a second version dimension within the GIT/SVN revision: the SQL versions. This forces us to take all database versions that have ever existed into a GIT/SVN checkout.
Conflicts in database change scripts are manual merge work.
Conflicts in database change scripts are, as a rule, not noticed (two people insert the same column with different names).
There is no GUI for the Liquibase process.
Native Liuqibase changesets are not cross-database.
If you decide to use Hibernate plugins (like Enver or Audit) additional customizations to Liuqibase are needed.

How does Release Manager (RM) do that?

The database entities always come up to date from Release-Manager as a dynamic Maven artifact. That’s it! It’s simple.

This frees you from migration scripts, so you don’t have to merge. You don’t need a framework in the app. One doesn’t need additional tables. You don’t need a database connection to build. There are basically no contradictions between entities and database. Databases from other database vendors are specified as artifact versions and there is no need to rewrite Liquibase scripts.

Liquibase	Release manager
Start is delayed	Start is not delayed
Creating the Liquibase scripts puts a load on the database	Database is not loaded
Liquibase needs additional tables	No additional tables are needed
The application has Liquibase as a component	The application has no additional component
Liquibase can fail at runtime	Release manager stays out of runtime
Liquibase burdens version management	Release manager stays out of version management
Conflicts with Liquibase scripts are possible	There are no such conflicts with Release Manager. Only the concrete truth.
Contradictions in scripts are not noticed	Contradictions are possible, but arise where they are noticed: At the concrete database structure.
There is no Liquibase GUI	The release manager has a web interface.
Liquibase needs to be adapted to plug-ins	The release manager does not need any adaptations.

Lorsque l’on travaille avec des bases de données basées sur SQL, il existe deux sources principales de modification des schémas :

création d’une nouvelle base de données (CREATE DATABASE)
Modification/migration de la structure de la base de données (ALTER TABLE, ALTER COLUMN, etc.).

La modification de la structure de la base de données s’effectue via des scripts SQL. Ces scripts SQL peuvent :

Créer, renommer et supprimer des vues, des tables et des colonnes.
Modifier les types, les valeurs par défaut, les nullabilités et les auto-incréments et les dimensions des colonnes (parfois aussi les règles et les déclencheurs).
Modifier des valeurs dans la base de données (par exemple pour corriger des valeurs non nulles ou pour correspondre à des foreign-keys).

Tous ces scripts SQL peuvent également échouer. Même si deux bases de données ont la même structure, la migration peut fonctionner pour une base de données et échouer pour l’autre.

Des outils ont donc été créés pour s’occuper de la migration.

Pourquoi pas Liquibase:diff ?

Liquibase:diff crée des scripts utilisables pour la migration. Ces scripts sont souvent versionnés avec GIT ou SVN. La recréation de bases de données est donc possible directement à partir des sources du projet, ce qui est une bonne chose. Au démarrage de l’application, Liquibase introduit les modifications qui n’ont pas encore été enregistrées. Il y a cependant quelques critiques à formuler :

Le démarrage de l’application est retardé parce que Liquibase vérifie la base de données par rapport aux entités, alors que le framework de persistance le fait aussi.
La création des scripts Liquibase surcharge la base de données.
Liquibase a besoin de tables supplémentaires pour savoir quels scripts ont déjà été exécutés, ce qui fait gonfler la base de données.
L’application entière est légèrement gonflée et dépendante de Liquibase en tant que composant, Liquibase prend donc de la mémoire (au-delà du démarrage).
Liquibase peut échouer si un script SQL échoue, le déploiement échoue donc très tard. Cela se produit généralement lorsque : le schéma convient mais que le contenu de la base de données ne convient pas. Cela se produit également lorsque le serveur de base de données n’a pas assez de mémoire pour la modification de la base de données.
Celui qui intègre des scripts liquibase dans GIT/SVN a dans une révision GIT/SVN toutes les modifications historiques de la base de données, dans chaque version existante, même celles qui sont dépassées, même celles qui sont développées. Nous avons donc une deuxième dimension de version au sein de la révision GIT/SVN : les versions SQL. Nous sommes ainsi contraints de prendre en compte toutes les versions de la base de données qui ont existé dans une vérification GIT/SVN.
Les conflits dans les scripts de modification des bases de données sont un travail de fusion manuel.
Les contradictions dans les scripts de modification de la base de données ne sont généralement pas remarquées (deux personnes insèrent la même colonne avec des noms différents).
Il n’y a pas d’interface utilisateur graphique pour le processus Liquibase.
Les changesets Liuqibase natifs ne sont pas communs à tous les fournisseurs de bases de données.
Si l’on opte pour des plugins Hibernate (comme Enver ou Audit), des adaptations supplémentaires de Liuqibase sont nécessaires.

Comment s’y prend le gestionnaire de versions (RM)?

Les identités de la base de données sont toujours actualisées par le Release-Manager sous forme d’artefact Maven dynamique. C’est tout ! C’est très simple.

On est ainsi libéré des scripts de migration, on ne doit donc pas faire de merge. On n’a pas besoin de framework dans l’application. Pas besoin de tables supplémentaires. Pas besoin de connexion à la base de données pour construire. Il n’y a en principe pas de contradiction entre les entités et la base de données. Les bases de données d’autres fabricants de bases de données sont indiquées comme version d’artefact et il n’est pas nécessaire de réécrire les scripts Liquibase.

Liquibase	Gestionnaire de release
Le démarrage est retardé	Le démarrage n’est pas retardé
La création des scripts Liquibase surcharge la base de données.	La base de données n’est pas sollicitée
Liquibase nécessite des tables supplémentaires	Aucune table supplémentaire n’est nécessaire
L’application a Liquibase comme composant	L’application n’a pas de composant supplémentaire
Liquibase peut échouer lors de l’exécution	Le gestionnaire de versions reste en dehors de l’exécution
Liquibase surcharge la gestion des versions	Le gestionnaire de release reste en dehors de la gestion des versions
Conflits possibles avec les scripts Liquibase	Avec le gestionnaire de release, il n’y a pas de conflits de ce type. Seulement la vérité concrète.
Les contradictions dans les scripts ne sont pas remarquées.	Les contradictions sont possibles, mais elles apparaissent là où on les remarque : Au niveau de la structure concrète de la base de données.
Il n’y a pas de GUI Liquibase.	Le release manager a une interface web.
Liquibase doit être adapté aux plug-ins.	Le gestionnaire de versions ne nécessite aucune adaptation.

Cuando se trabaja con bases de datos basadas en SQL, hay dos fuentes básicas para los cambios de esquema:

Creación de una nueva base de datos (CREATE DATABASE).
Modificación/migración de la estructura de la base de datos (ALTER TABLE, ALTER COLUMN, etc.).

La estructura de la base de datos se modifica mediante secuencias de comandos SQL. Estos scripts SQL pueden:

Crear, renombrar y eliminar vistas, tablas y columnas.
Cambiar tipos, valores por defecto, nulidades y autoincrementos y dimensiones de columnas (a veces también reglas y triggers).
Modificar valores en la base de datos (por ejemplo, para corregir valores no nulos o hacer coincidir claves ajenas).

Todos estos scripts SQL también pueden fallar. Aunque dos bases de datos tengan la misma estructura, la migración puede funcionar en una y fallar en la otra.

Así que se crearon herramientas para encargarse de la migración.

¿Por qué no Liquibase:diff?

Liquibase:diff crea scripts utilizables para la migración. Estos scripts suelen versionarse con GIT o SVN. Por lo tanto, se pueden crear nuevas bases de datos directamente a partir de las fuentes del proyecto, lo cual es algo bueno. Cuando se inicia la aplicación, Liquibase importa los cambios que aún no se han introducido. Sin embargo, hay algunas críticas:

El inicio de la aplicación se retrasa porque Liquibase comprueba la base de datos con las entidades, aunque el marco de persistencia hace lo mismo.
La creación de los scripts Liquibase supone una carga para la base de datos.
Liquibase necesita tablas adicionales para averiguar qué scripts se han ejecutado ya, lo que sobrecarga la base de datos.
Toda la aplicación se hincha un poco y depende de Liquibase como componente, por lo que Liquibase ocupa memoria (más allá del inicio).
Liquibase puede fallar si falla un script SQL, por lo que el despliegue falla muy tarde. Esto suele ocurrir cuando: el esquema encaja pero el contenido de la base de datos no. También ocurre cuando el servidor de base de datos no tiene suficiente memoria para el cambio de base de datos.
Si pones scripts liquibase en GIT/SVN, tienes todos los cambios históricos de la base de datos en una revisión GIT/SVN, en cada versión que haya existido, incluso las obsoletas, incluso las actualizadas. Así que tenemos una segunda dimensión de versión dentro de la revisión GIT/SVN: las versiones SQL. Esto nos obliga a tomar todas las versiones de la base de datos que han existido en un checkout GIT/SVN.
Los conflictos en los scripts de cambio de base de datos son un trabajo de fusión manual.
Por regla general, los conflictos en los scripts de modificación de la base de datos pasan desapercibidos (dos personas insertan la misma columna con nombres diferentes).
No hay interfaz gráfica de usuario para el proceso Liquibase.
Los cambios nativos de Liuqibase no son entre bases de datos.
Si decide utilizar plugins de Hibernate (como Enver o Audit) será necesario realizar ajustes adicionales en Liuqibase.

¿Cómo lo hace Release Manager (RM)?

Las entidades de la base de datos siempre se actualizan desde Release-Manager como un artefacto dinámico de Maven. ¡Eso es! Es muy sencillo.

Esto le libera de las secuencias de comandos de migración, por lo que no tiene que fusionar. No necesitas un marco en la aplicación. No necesitas mesas adicionales. No necesitas una conexión a la base de datos para construir. Básicamente, no hay contradicciones entre las entidades y la base de datos. Las bases de datos de otros fabricantes de bases de datos se especifican como versiones de artefactos y no es necesario reescribir los scripts de Liquibase.

Liquibase	Gestor de publicaciones
El inicio se retrasa	El inicio no se retrasa
La creación de los scripts Liquibase sobrecarga la base de datos	La base de datos no está cargada
Liquibase necesita tablas adicionales	No se necesitan mesas adicionales
La aplicación tiene Liquibase como componente	La aplicación no tiene ningún componente adicional
Liquibase puede fallar en tiempo de ejecución	El gestor de versiones permanece fuera del tiempo de ejecución
Liquibase carga la gestión de versiones	El gestor de versiones se mantiene al margen de la gestión de versiones
Es posible que se produzcan conflictos con los scripts de Liquibase	Con Release Manager no existen estos conflictos. Sólo la verdad concreta.
Las contradicciones en los guiones pasan desapercibidas	Las contradicciones son posibles, pero surgen allí donde se notan: En la estructura concreta de la base de datos.
No hay interfaz gráfica de Liquibase	El gestor de versiones dispone de una interfaz web.
Liquibase debe adaptarse a los plug-ins	El gestor de versiones no necesita ninguna adaptación.

在处理基于SQL的数据库时，有两个基本的模式变化来源。

创建一个新的数据库（CREATE DATABASE）。
改变/迁移数据库结构（ALTER TABLE，ALTER COLUMN，等等）。

数据库结构是用SQL脚本改变的。这些SQL脚本可以。

创建、重命名和删除视图、表和列。
改变类型、默认值、无效性和自动递增以及列的尺寸（有时也包括规则和触发器）。
改变数据库中的值（例如，纠正非空值或匹配外国键）。

所有这些SQL脚本也可能失败。即使两个数据库具有相同的数据库结构，迁移也可能在一个数据库上工作，而在另一个数据库上失败。

因此，创建了一些工具来处理迁移问题。

为什么不是Liquibase:diff？

Liquibase:diff为迁移创建了可用的脚本。这些脚本通常用GIT或SVN进行版本管理。因此，新的数据库可以直接从项目源中创建，这是一件好事。当应用程序启动时，Liquibase会导入尚未输入的更改。然而，也有一些批评意见。

应用程序的启动被延迟了，因为Liquibase会根据实体检查数据库，尽管持久化框架也会这样做。
Liquibase脚本的创建给数据库带来了负荷。
Liquibase需要额外的表来查找哪些脚本已经被执行，这使数据库变得臃肿。
整个应用程序变得略微臃肿，并依赖于Liquibase这个组件，所以Liquibase占用了内存（超出了起始点）。
如果SQL脚本失败，Liquibase就会失败，所以部署失败得很晚。这通常发生在：模式适合但数据库内容不适合。当数据库服务器没有足够的内存进行数据库变更时也会发生这种情况。
如果你把liquibase脚本放到GIT/SVN中，你就会在GIT/SVN的修订版中拥有所有的历史数据库变化，在每一个曾经存在的版本中，甚至是过时的版本，甚至是升级的版本。所以我们在GIT/SVN修订版中还有第二个版本维度：SQL版本。这迫使我们把所有曾经存在过的数据库版本带入GIT/SVN检查。
数据库变更脚本中的冲突是手动合并工作。
数据库更改脚本中的冲突通常不会被注意到（两个人以不同的名字插入同一列）。
Liquibase过程没有GUI。
原生的Liuqibase变化集不是跨数据库的。
如果你决定使用Hibernate插件（如Enver或Audit），将需要对Liuqibase进行额外的调整。

发布管理器（RM）是如何做到这一点的？

数据库实体总是作为一个动态的Maven工件从Release-Manager中得到更新。就这样吧!这很简单。

这就把你从迁移脚本中解放出来了，所以你不必再进行合并。你在应用程序中不需要一个框架。你不需要额外的表格。你不需要数据库连接来构建。实体和数据库之间基本上没有矛盾。来自其他数据库制造商的数据库被指定为人工制品版本，无需重写Liquibase脚本。

液化基地	发布经理
启动被推迟	启动没有延迟
创建Liquibase脚本会给数据库带来负担	数据库未加载
Liquibase需要额外的表	不需要额外的表格
该应用程序将Liquibase作为一个组件	该应用程序没有额外的组件
Liquibase在运行时可能失败	发布管理器保持在运行时间之外
Liquibase给版本管理带来负担	发布经理不参与版本管理
与Liquibase脚本的冲突是可能的	有了Release Manager，就没有这种冲突了。只有具体的事实。
脚本中的矛盾没有被注意到	矛盾是可能的，但在被注意到的地方就会出现矛盾。在具体的数据库结构中。
没有Liquibase的GUI	发布管理器有一个网络界面。
Liquibase需要适用于插件	发布管理器不需要进行任何调整。