Discussion :

[CinePhil]

Bonjour,

Soit une sauvegarde avec mysqldump :

Code bash :

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

mysqldump -u user_backup -p -C -Q -e --routines --triggers --create-options labdd | gzip > /chemin/vers/fichier/sauvegarde.sql

Je viens de tester une restauration dans une BDD créée spécialement pour le test :

Code bash :

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

mysql -u user_admin -p labdd_rest < /chemin/vers/fichier/sauvegarde.sql

No problem pour la restauration des tables et des données mais les vues apparaissent dans la liste des tables et les procédures ne sont pas restaurées.

J'ai remarqué depuis longtemps deux choses dont je n'ai jamais compris l'utilité :
1) Pour les vues, mysqldump enregistre des commandes de création de structure de table puis supprime cette table avant la commande de création de la vue.
=> Mais pourquoi ?

2) Pour les procédures et les vues est apparu depuis quelques temps un DEFINER.
Quand le DEFINER du fichier de dump n'est pas un utilisateur MariaDB sur le serveur sur lequel on restaure, ça plante.

Là a priori pas de problème de DEFINER puisque c'est sur le même serveur donc l'utilisateur y est. Ce qui change, c'est le nom de la BDD de restauration.

[SQLpro]

...
J'ai remarqué depuis longtemps deux choses dont je n'ai jamais compris l'utilité :
1) Pour les vues, mysqldump enregistre des commandes de création de structure de table puis supprime cette table avant la commande de création de la vue.
=> Mais pourquoi ?

C'est sans aucun doute lié au fait qu'il n'a pas de catalogue système ce qui lui pose des problèmes sans nom....

En effet dans tous les autres SGBDR, les métadonnées de la base (table, colonne, index, vues, routines, procedures...) sont stockées dans des tables systèmes. Or MySQL est le seul qui n'en possède pas.... Cela a des conséquences tragiques d'ailleurs car en cas de suppression des fichiers d'une table, aucune trace, tu ne peut pas le savoir. par exemple sous PG si tu supprime les fichiers d'une table, il va râler (de manière interne, mais il va râler....). Je suppose donc, que pour conserver quand même une trace de cette vue, il doit créer un fichier (de table !!!!). C'est aussi pourquoi les vues MySQmerde c'est de la m.... Car en fait il exécute un SELECT * sur le SQL contenu dans le fichier, le stocke dans une table temporaire qui va servir à la requête finale.... Bref, infâme au niveau des performances....

Codd le faisait remarquer il y a longtemps....

A +

[fsmrel]

Codd le faisait remarquer il y a longtemps...

Que veux-tu dire ? Que Codd montre MySQL du doigt ?
Ou bien fais-tu allusion à la 4e de ses 12 règles (catalogue actif) ?

[CinePhil]

Il y a effectivement un fichier .frm pour chaque vue ; je n'avais jamais remarqué ça !

Bon tout ça ne résout pas mon problème.

[SQLpro]

Que veux-tu dire ? Que Codd montre MySQL du doigt ?
Ou bien fais-tu allusion à la 4e de ses 12 règles (catalogue actif) ?

yes !!!!

Extrait de mon bouquin à paraître :



A +

[CinePhil]

Je retombe par hasard sur ma question...

De mémoire (et je l'ai encore fait hier), l'ajout de l'utilisateur d'origine dans la BDD résout le problème.
Si vous avez DEFINER 'toto'@'localhost' dans le script du dump, vous ajoutez le user 'toto'@'localhost' avec les bons privilèges sur la BDD et la restauration se passe bien.

Du moins en version MariaDB 10.4.