Discussion :

[CinePhil]

Bonjour,

J'ai actuellement une BDD sur :
- mon poste de travail pro ;
- mon poste de télétravail ;
- le serveur de développement.

Deux autres collègues travaillent aussi sur leur poste de travail et tout est consolidé sur le serveur de dev.
Viendra le moment où il faudra exporter ça sur un serveur de prod.

Quand on fait un export de la BDD avec phpMyAdmin, la réinjection sur un autre poste pose de gros problèmes :
- les foutus DEFINER qui empêchent l'utilisateur applicatif d'utiliser les vues ;
- des vues qui ne sont pas forcément sauvegardées dans le bon ordre, ce qui engendre des erreurs lorsqu'une vue en appelle une autre...

Avec la commande suivante, j'ai un résultat un peu plus exploitable :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump -u un_user_qui_a_les_droits -p -c --default-character-set=utf8 -K -F --order-by-primary --skip-quote-names -R -B la_bdd > chemin/vers/fichier.sql

Au fil du temps vont arriver des patches améliorant ou complétant la structure de la BDD, ses vues et ses procédures.

QUESTION :
Est-il possible de lancer un script sql qui en appelle d'autres afin de charger en enfilade les scripts de toutes les procédures et vues qui ont été dernièrement modifiées, ainsi que les scripts DDL et DML modifiant la structure ou les données de référence ?

Sur Oracle, c'est faisable. Mais avec MySQL/MariaDB ?

[CinePhil]

J'ai trouvé !

Par exemple, pour enchaîner un script TEST_DDL.sql puis TEST.DML.sql, on crée ce fichier par exemple TEST_PATCH.sql :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
use test;
source TEST_DDL.sql;
source TEST.DML.sql;

et on lance ça en bash :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql -u mon_user -p test < TEST_PATCH.sql

Et ça fonctionne nickel ! Même pas besoin de transférer les fichiers dans le répertoire mysql.

[Artemus24]

Salut CinePhil.

Viendra le moment où il faudra exporter ça sur un serveur de prod.

La bonne façon de faire est de créer un environnement de test conforme à ce que l'on désire obtenir au final dans la production.
J'espère que vous n'allez pas transférer l'environnement de développement directement en production, sans faire des tests de fonctionnalités, d'intégration, de performance ...

Quand on fait un export de la BDD avec phpMyAdmin, la réinjection sur un autre poste pose de gros problèmes :

Si je devais faire un transfert en constituant un autre environnement, je n'aurai pas utilisé phpmyadmin.

Si l'ordre à de l'importance, vous devez traiter étape par étape le transfert :
1) exporter chaque table (create + insert) indépendamment dans l'ordre le plus adapté.
Attention à la volumétrie. Utiliser l'autocommit puisque vos données sont valides.
2) exporter ensuite les view, les déclencheurs, les fonctions, les événements, les procédures stockées.
3) recréer l'environnement en testant la volumétrie dont vous avez besoin.
4) importer chaque table indépendamment les unes des autres, dans l'ordre qui vous convient le mieux, sans activer les index.
5) activer les index quand les données auront été chargées.
6) puis importer les déclencheurs, les fonctions, les événements, les procédures stockées.
7) ne pas oublier de procéder au final à optimisation.

Cela implique de créer autant de scripts qu'il y a d'objets à transférer.

Est-il possible de lancer un script sql qui en appelle d'autres afin de charger en enfilade les scripts

En enfilade, ce n'est pas la bonne façon de faire. Pourquoi ?
Imaginez que vous ayez un plantage à la fin de votre script SQL.
Le traitement a duré disons 3 heures et vous devez tout recommencez.
Perte de temps, juste pour refaire ce qui a déjà été validé.

Je déconseille d'utiliser "source", puisque vous ne pourrez pas introduire des points de reprises.

Dans le batch qui va chapeauter tous les scripts sql, vous devez mettre des étiquettes.
Chaque étape sera répertoriée par une étiquette et est indépendante les unes des autres.
Si vous devez relancez le script batch, il suffit de dire à quelle étiquette.

@+

[CinePhil]

Merci pour la réponse.

Ce ne sera pas une grosse base. Au moins les deux tiers sont déjà développés ; ça ne fait que quelques dizaines d'objets et 70 000 lignes. D'ici la mise en production, on ne dépassera pas les 80 000 lignes et au fil du temps en production, je serai en retraite avant que ça atteigne les 100 000 lignes.

L'import actuel ne prend qu'environ une minute, de mémoire.

Mais je vais quand même réfléchir à la méthode que tu proposes, même si je trouve ça lourd de faire un script bash qui lance des dizaines de fois une commande mysql qui lance un script SQL.

[Artemus24]

Salut CinePhil.

La question est de savoir où tu veux perdre du temps.
Est-ce dans la conception de ton script ou bien durant la phase de migration ?
Ce que tu gagnes d'un coté, tu peux le perdre de l'autre coté. A toi de déterminer ce qui est le plus urgent !

Je préfère blinder mon script, de faire des tests avant le jour fatidique de la migration, pour me rendre compte des problèmes que je peux éventuellement rencontrer.
Et le jour de la migration, je n'aurai presque rien à faire, juste regarder le déroulement des différentes phases.
Peut-être une reprise au cas où il y a un problème de volumétrie.

Dans ma jeunesse, j'ai fait des migrations de données et de traitement de BULL vers IBM (gros système) et cela durait un week-end entier.
Nous rencontrions deux problèmes à savoir l'optimisation des temps de traitement, et la volumétrie.
Et je ne parle même pas de l'ordonnancement des différentes phases car pour gagner du temps, nous devions traiter cela en parallèle.

@+