なぜ、いつLiquibaseですか？

スタックオーバーフローでこの質問を検索しようとしましたが、これに関する質問は見つかりませんでした。
私は新しいLiquibaseので知りたい です

• なんでLiquibase？
• Liquibaseプロジェクトで使用する必要があるのはいつですか？

これはすべてのデータベースの変更を1か所にSQL保持することですが、リポジトリシステムで単純なファイルを作成し、時間の経過とともに更新し続けることによっても同様のことができます。

自己管理スキーマ作成ファイルとLiquibase（または他のスキーマ移行ツール）の主な違いは、後者がスキーマ変更ログを提供することです。これは、時間の経過に伴うスキーマの変更の記録です。これにより、データベース設計者はスキーマの変更を指定でき、必要に応じてスキーマのプログラムによるアップグレードまたはダウングレードが可能になります。

他にも次のような利点があります。

• データベースベンダーの独立性（これは疑わしいですが、彼らは試みます）
• 自動ドキュメント
• データベーススキーマの差分

1つの代替ツールはflywayです。

データを失うことなくスキーマの更新を自動的に管理する必要がある場合は、スキーマ移行ツールを使用することを選択します。つまり、システムが顧客サイトや安定したテスト環境などの長期的な環境に展開された後に、スキーマが変更されることを期待しています。

スキーマの変更に関して、liquibaseが開発者の間で規律を作り出すのを見てきました。他の開発者の変更を上書きして実行することはできません。代わりに、独自のチェンジセットを作成し、実行する一連の変更の最後に追加します。これにより、いつどのような変化が生じ、誰がそれをもたらしたのかが明確になります。

スキーマの保守に対する非常に「バージョン管理された」アプローチ。

手始めに、それは「不必要な仕事」のような印象を与えます。

開発、QA、本番環境に複数のデータベースインスタンスがあり、変更履歴を自動的に追跡してインテリジェントに変更を適用するツール（現在のスキーマと最終スキーマの差分を適用）が必要な場合、リキベースやフライウェイなどのツールが非常に役立ちます。

Liquibaseは、データベースが後付けであるという哲学のもとで優れていると思います。この哲学は、本番環境で不良データベースの大部分を引き起こし、それらのほとんどは不良です。データベースは、ビジネスシステム全体の全体像を考慮して設計する必要があります。それぞれが独自のサイロで作業しているアプリケーション開発者によって統合されているわけではありません。後者の方法では、回避策、非正規化されたデータ、テーブル間の不適切な関係、ビジネスエリアの重複、および原因となる問題が原因で展開直後にクライアントが煩雑でメンテナンス費用がかかるシステムが発生します。データベースがビジネス関係を正確に反映するように設計されている場合、その寿命は5倍の長さであり、残念ながらほとんどの場合のように、段階的に設計されたものよりも5倍優れた目的を果たします。

Liquibase自体は問題ではありませんが、アプリケーション開発者がデータベースを設計する練習を可能にします。それは問題。

以下の記事を読んでリキベースが答えられる理由 http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.htmlを

それを注意深く読んだ場合、単純なmvnコマンドまたはCLIコマンドの助けを借りて、上位バージョンから下位バージョンにダウングレードする機能は非常に便利です。これらのスクリプトを手動で実行する必要があります。また、次のような変更セットはありません。

私のチームのDevOps担当者であるため、すべてのSQLファイルを1か所、つまりSCM（ソースコード管理）に配置したい

CI中も / CDフェーズ DBスキーマが作成されると、時間とリソースを大幅に節約できます。そのクライアントのデータベースを管理する別の人がいる必要はありません。

Flyway、Liquibase、EFなどのORMは、これを達成するのに役立ちます。