Pourquoi et quand Liquibase?
J'ai essayé de rechercher cette question sur stack overflow mais je n'ai trouvé aucune question pour cela. Je suis nouveau sur liquibase et je veux savoir pourquoi liquibase? Et quand exactement on devrait utiliser liquibase dans le projet?
Je sais que c'est pour garder tous les changements de base de données en un seul endroit, mais le même peut être fait en créant un simple fichier sql dans un système de référentiel et continuer à le mettre à jour avec le temps.
4 réponses
Le différenciateur clé entre un fichier de création de schéma autogéré et Liquibase (ou d'autres outils de migration de schéma ) est que ce dernier fournit un changelog de schéma. Ceci est un enregistrement des changements de schéma au fil du temps. Il permet au concepteur de base de données de spécifier changes dans le schéma et active la mise à niveau ou la rétrogradation programmatique du schéma à la demande.
Il y a d'autres avantages, tels que:
- indépendance du fournisseur de la base de données (c'est discutable, mais ils essayez)
- documentation automatisée
- diffs du schéma de base de données
Un autre outil est voie de migration .
Vous choisissez d'utiliser un outil de migration de schéma lorsque vous souhaitez ou devez gérer automatiquement les mises à jour de schéma sans perdre de données. Autrement dit, vous vous attendez à ce que le schéma change une fois que votre système a été déployé dans un environnement de longue durée, tel qu'un site client ou un environnement de test stable.
J'ai vu liquibase créer de la discipline parmi les développeurs quand il s'agit de modifier le schéma. Vous ne pouvez tout simplement pas écraser le changement d'un autre développeur et l'exécuter . Au lieu de créer votre propre ensemble de modifications, ajouter à la fin de la séquence de changements pour être exécuté. Cela apporte également de la clarté sur ce changement est venu quand et qui l'a apporté.
Une approche très "versionnée" de la maintenance du schéma.
Pour commencer, cela donne une impression de "travail inutile".
Lorsque vous avez plusieurs instances de base de données dans dev, qa, production et que vous voulez avoir un outil pour suivre automatiquement l'historique des modifications et appliquer les modifications intelligemment (appliquer le diff du schéma actuel et du schéma final), des outils comme liquibase ou flyway seront très utiles.
Je crois que Liquibase est génial quand votre philosophie est que la base de données est une réflexion après coup. Cette philosophie a causé la majorité des mauvaises bases de données en production-et la plupart d'entre eux sont mauvais. Une base de données devrait être conçue avec une vue complète de l'ensemble du système d'entreprise, pas en morceaux par les développeurs d'applications travaillant chacun dans leurs propres silos. Cette dernière méthode se traduit par des solutions de contournement, des données dénormalisées, de mauvaises relations entre les tables, une duplication des secteurs d'activité et un système désordonné et à coût de maintenance élevé que le client détestera peu de temps après le déploiement en raison des problèmes qu'il provoque. Si une base de données est conçue pour refléter avec précision les relations d'affaires, sa durée de vie sera 5 fois plus longue et servira son objectif 5 fois mieux que celui conçu de manière fragmentaire comme malheureusement la plupart sont.
Liquibase n'est pas un problème en soi, mais il permet la pratique que les développeurs d'applications conçoivent la base de données. C'est le problème.