Versionner le modèle d'une base de donnée

Bonjour,

Je débute dans le monde des applications web, et ayant l’habitude de versionner mes projets avec Git, je me suis demandé quelle était la meilleure manière de versionner le modèle d’une base de donnée (MySQL en l’occurrence).

D’après quelques recherches sur le web, il suffirait de faire un dump de la base de donnée (mais sans les données) dans un fichier, puis de versionner ce dernier.

1
2
3

mysqldump -h localhost -u root maBDD --no-data > bdd.sql
git add bdd.sql
git commit

Qu’en pensez-vous ? Qu’en est-il de la base de donnée de ZdS ?

Pour simplifier, en général, tu utilise un ORM (ou outils similaires) pour décrire ton modèle de donnée. Du coup ce n’est que du code qui est versionné de façon classique. Faire des requêtes à la main est toujours possible mais surtout pour les chemins critiques, pas pour les bases.

Merci pour les réponses.

Donc si j’ai bien compris, un ORM est une couche d’abstraction sur la base de donnée ? Car autant je vois comment cela pourrait remplacer des requêtes (SELECT, INSERT, etc.), autant je ne suis pas sûr de comment ni où je devrais définir mon modèle.

Pour info, il s’agit d’un petit projet en PHP (sans framework à priori) sur lequel je bosse seul, dans le but principal de m’entraîner. Je me demande si définir le modèle avec un ORM serait pas un peu overkill, voire même plus compliqué qu’avec des outils pour manipuler la base de donnée. Je suis d’ailleurs pas sûr de voir l’avantage sur le fait de versionner un dump de la base de donnée (il s’agirait aussi de code, mais généré automatiquement).

Je connais pas le PHP mais en python, avec Django ou sqlAlchemy, définir le modèle revient à écrire une classe qui la représente. Par exemple pour créer un modèle pour un utilisateur tu pourrais faire  :

1
2
3
4
5

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

Donc ta classe est versionné. Ensuite l’orm peut gérer pour toi comment transformer les donnés (quand tu rajoute ou supprime des colonnes par exemple).

Je sais pas si ça existe en PHP pur, ni si ça existe en PHP hors des framework, mais à titre personnel je trouve ça loin d’être overkill et vraiment très pratique.

autant je ne suis pas sûr de comment ni où je devrais définir mon modèle.

Dans les migrations, comme indiqué.

Tu versionnes déjà ton code avec git, et c’est très bien. Du coup tu peux revenir à l’état de ton projet à l’instant T. Tu peux voir comment le projet a évolué niveau code. Par contre si ce n’est pas ton code qui créé les tables et les manipules (ce qu’on appelle des migrations), ton code n’est pas utilisable, et ton versionnage est foireux. Tu peux pas revenir 3 mois en arrière et faire tourner ton projet : il manque l’état de la base de donnée.

Stocker l’état de la base de donnée n’est pas intéressant non plus, il faudrait le faire à chaque commit. Remarque qu’un commit n’est pas l’état du projet, mais une modification du code. Idem pour les migrations : c’est pas l’état de la base de donnée mais les étapes pour arriver à l’état.

Ok je vois plus ou moins le truc.

Cependant je ne vois pas en quoi la variante avec mysqldump ne serait pas viable. Imaginons : je dump le modèle de la base de donnée dans un fichier bdd.sql que j’inclus dans mon dépôt. Puis, quelques jours plus tard, j’ajoute une colonne dans une table : je refais un dump et j’écrase l’ancien, puis je commit. Ainsi, si je veux revenir à une ancienne version du projet, il me suffit de rollback sur un commit précis, puis de faire un mysql -u root maBDD < bdd.sql pour remettre le modèle de la base de donnée dans le bon état.

Certes, c’est sans doute moins propre qu’avec les bons outils dédicacés, mais ça me permet de pouvoir profiter de n’importe quelle interface plus ergonomique pour définir le modèle.

Pour le coup, un commit avec git est bien un instantané et non pas une "liste de modifications". Mais quelle différence pour l’utilisateur ? On peut générer la différence à partir de deux états, ou générer deux états à partir d’une différence.

Un commit est un patch, un diff. C’est pas un état du projet, non. Il y a une grosse différence.

Le gros problème avec ça, c’est que si il y a des données dans la base de données, ils sont supprimés, vu que tu crées une nouvelle base de données. Les migrations définissent des changements dans la base de données.

Et pour les librairies pour des migrations, je sais qu’il en existe en PHP des framework-agnostic, regarde la liste awesome-php (sous mobile, je te laisse chercher).

Oui en effet, je n’y avais pas pensé dès le début. Mais durant le développement initial du projet, je n’aurai pas de données (si ce n’est pour tester). Du coup je pourrais techniquement me passer des migrations avant la première version stable.

Petite question, je comprend bien à quoi va servir le fichier de migration, mais je ne vois pas trop comment faire un rollback. A quoi ressemble un fichier de migration ?

Voici un fichier de migration de ZdS qui ajoute des champs aux modèles du forum pour utiliser Elasticsearch.

Un fichier de migration est un fichier comme un autre, donc on peut revenir en arrière comme on le ferait pour un autre fichier (si on n’a pas effectué la migration du coup). Sinon, il est aussi possible de créer un autre fichier de migration qui va annuler ce qu’on a fait.

En fait ce qui est un peu déroutant, c’est que jusqu’à maintenant, j’écrivais du PHP uniquement pour générer mes pages web, en d’autres termes, des scripts exécutés automatiquement par Apache à chaque requête.

Or avec ces migrations, ce serait du code qu’il faut exécuter soi-même pour modifier l’état de la base donnée. Comment cela se déroule-t-il si le site web est sous un hébergement mutualisé ? Ça reste possible ?

Ça dépend de ton hébergeur, mais de toute façon tu rencontreras exactement le même problème en utilisant des dump sql.

Dans les deux cas, tu dois mettre à jour là structure de ta bdd. Si ton hébergeur te donne un accès console en SSH, tout est bon, sinon tu dois te créer un accès Web. C’est ce que fait phpmyadmin, par exemple : l’outil te donne un accès Web pour administrer ta bdd. Si tu préfères utiliser les migrations plutôt que les dump, tu devras créer toi-même ton interface (édit : une simple page d’administration qui exécute tous les scripts de migration pas encore exécutés, dans l’ordre chronologique. Bien sûr il te fait une table en bdd où tu stockrs le numéro de la dernière version). Ce n’est pas compliqué, et je me demande même s’il n’y a pas déjà des outils pour ça, tout comme phpmyadmin.

(Oui, 10 jours plus tard, j’assume )

En recherchant un petit peu, je suis tombé sur Phinx, d’après ce que j’ai pu lire ça correspond plus ou moins à ce que tu cherches. (Par contre il te faut un accès SSH).

Sinon il faut essayer de chercher sur internet database migration php tool voir si tu trouves quelques chose d’intéressant. Autant ne pas réinventer la roue.

En fait, les hébergeurs ne donnent-ils pas des identifiants pour se connecter directement à la base de donnée distante ? Si oui, il suffirait d’exécuter les scripts en local et d’envoyer les changement directement sur la base de donnée, non ?

À propos (mais un peu HS), je viens de voir qu’OVH propose des VPS SSD à partir de 3€ par mois. Je trouve le prix relativement bas comparé à un simple hébergement mutualisé. Qu’en pensez-vous ? Est-ce avantageux ?

Je suis tombé dessus aussi, il est assez simple à mettre en place, et propose même un exemple d’accès web.

À propos (mais un peu HS), je viens de voir qu’OVH propose des VPS SSD à partir de 3€ par mois. Je trouve le prix relativement bas comparé à un simple hébergement mutualisé. Qu’en pensez-vous ? Est-ce avantageux ?

C’est avantageux dans le cas où tu n’as pas peur de bidouiller dans le cambouis. Il faut que tu maîtrises Linux (tu as le choix de la distribution), soit Apache, Nginx, etc.

Mais l’un des gros avantages c’est que tu peux faire bien plus, comme faire tourner diango, un serveur de jeu, etc.

Par exemple, https://sonar.winxaito.com (le sonar cube de ZestWriter tourne sur mon VPS ovh).

Je me répète : si tu as besoin d’une librairie, regarde la liste awesome-php.

Pour le VPS, il faut que tu saches setup ton serveur, ce qui peut-être assez complexe pour avoir une sécurité maximale. À toi de voir.

Justement, je trouve ce point intéressant, mais je sais pas trop si le plan à 10 Go de SSD et 2 Go de RAM suffit pour faire tourner beaucoup d’autres choses qu’un serveur web (sachant qu’au même prix, on a 100 Go de stockage avec un hébergement web classique).

Encore faut-il voir à quel point c’est compliqué de mettre en place un serveur web sur un VPS, mais c’est une autre histoire.

Je n’ai pas pris la peine de le préciser, mais je suis bien tombé sur Phinx grâce à ce lien dans ton premier message. D’ailleurs, merci pour cette liste, je ne la connaissais pas.

Tant que tu ne proposes pas d’hébergement d’image/vidéo/doc/etc, je ne pense pas que les 10Go soient un gros problème. Le problème que tu auras sera plus au niveau des perfs bruts, je pense. Tu dois pouvoir trouver des benchmarks des différentes offres (je n’ai jamais cherché, mais j’imagine).