Git pour les bases de données ?
Bonjour à tous,
J'ai longtemps ignoré le versioning et l'utilisation de Git mais depuis que je l'ai ajouté à mes projets je réalise la puissance de cet outil et la tranquilité d'esprit qu'il permet d'avoir quand on explore une nouvelle voie qui risque de compromettre toute l'intégrité du code déjà écrit.
Je voudrais savoir si il y a des outils qui permettent d'avoir les mêmes bénéfices quand on travaille avec des bases de données ? quelles sont les bonnes pratiques ou outils dans le monde pro quand on manipule des BDD pour éviter de tout crassher suite à une mauvaise manip du développeur (je ne parle pas ici de la sécurité côté utilisateur) ?
Actuellement j'ai une BDD MariaDB et ma seule action préventive consiste à faire un export de temps à autre et enregistrer le .sql dans un cloud.... ça me semble vraiment pas la meilleure option mais j'ai aucune idée des bonnes pratiques à ce sujet...
5 réponses
Hello :)
Alors le versioning ça fonctionne parce que c'est simplement une sauvegarde du code à telle date, pour ce qui est des bases de données, et bien la sécurité c'est exactement ce que tu fais déjà actuellement, ce sont des snapshots, en principe il y a une option dans l'hébergeur pour faire une sauvegarde régulière de la base, en pro la pratique c'est généralement un snapshot par jour avec un TTL de 30jours, ça permet que si la base crashe, on peut restaurer la base de données à partir des données de la veille.
Ca c'est pour la corruption innatendue de la base, ou une mauvaise manip genre tu drop ta base de prod, maintenant au niveau des requetes en elles mêmes, il faut faire en sorte de toujours passer par des transactions, en gros le code va enregistrer l'état initial de ta base, va exécuter ta requete, si ça passe, tant mieux, si ça casse, l'app va restituer les données initiales d'avant la requete, si tu es en PHP en principe c'est automatique, idem pour Ruby on Rails, ils ont des helpers transaction, mais c'est plus pour faire des chaines de requetes qui doivent toutes passer pour valider la transaction.
I asked myself the same question a while ago, and frankly, I found that tools like Liquibase or Flyway are super handy for versioning database schematics. You write your SQL migrations as you commit your code, and you can go back cleanly. Personally, I also keep regular dumps via automated scripts, which is reassuring. I think it's important to version both the code and the BDD structures to avoid unpleasant surprises.
Woow je viens de tomber un peu par hasard sur Git LFS qui semble répondre à ma problématique : https://git-lfs.com/ ! (ma base de données étant consultée presque exclusivement en lecture je songe à la convertir en .sqlite ce qui la rendrait compatible avec git... ou encore bien mieux : cet outil git LFS...)
Merci ! Je vais regarder la piste Liquibase si ce n'est pas trop compliqué à implémenter.
Dans l'idéal je cherchais un outil qui permette de restaurer la base de données à un état précédent avec la structure mais aussi les datas... pas sûr que cela existe réellement hormis bien sûr les sauvegardes automatiques du serveur de BDD.
Les pratiques que vous utilisez actuellement pour les sauvegardes de votre base de données ne sont pas mauvaises, mais elles peuvent être améliorées. Pour gérer les migrations de schéma, je vous recommande vivement d'adopter un outil comme Flyway ou Liquibase.
Merci Popotte ! Très étrange, je peux voir ton message seulement depuis aujourd'hui alors qu'il apparaît comme posté depuis 6 jours...
Je pense effectivement que je vais me contenter des sauvegardes auto regulières avec éventuellement quelques sauvegardes manuelles si nécessaire. Le truc c'est qu'il peut m'arriver de faire quelques grosses modifs manuellement sur ma BDD et si j'avais eu un système de "commit" ou même de "fork" ça m'aurait permis plus de granularité que la sauvegarde journalière pour tester des trucs.
Pour les transactions tu as raison, c'est quelque chose que je ne fais pas mais qu'il serait peut être bénéfique d'intégrer. Sur ce projet j'utilise Nuxt et la librairie mysql2, et j'envisage éventuellement de passer sur un ORM. C'est un step à franchir pour moi mais je crois comprendre que ça facilite la gestion des transactions.