Bonjour,
 
j'ai une petite question concernant les bases de données.
En effet, j'ai utilisé mysql pour me faire une base de données (serveur local) et j'aimerais exporter cette base de données vers un autre PC.
 
Existe t'il un moyen d'effectuer cette manipulation ?
 
Merci
Johnson

Oui, il doit y avoir dans l'interface MySQL une rubrique export/import...dans laquelle tu dois pouvoir choisir d'exporter toute la base (structure et données) ou seulement les données.
 
Cela te génère un fichier contenant en SQL les requetes de création de la base et des données.
De plus cela te permet de faire une sauvegarde en cas de souci.

Merci je vais voir cela tout de suite !

+1
 
fais attention de bien sélectionner la version de mysql vers laquelle tu veux exporter, car sur certaine console phpmyadmin, tu as le choix, et si tu ne choisis pas la bonne, ça peut ne pas fonctionner correctement (erreurs etc..)
 
De même tu peux soit les avoir sur l'écran soit les récupérer en fichier sql ou zip (ou tar il me semble).

juste comme ça... mysql n'a pas un module de backup/restore ? ça me semble bien plus adapté à ce genre de traîtements, car infiniment plus rapide et bien moins volumineux..

 
Si... tu fais un export, que tu peux zipper/Gzipper dans l'export  tu définis :
- SQL/Latex/CSV Excel/CSV/XML
- Commentaire d'en tête
- Mode transactionnel
- Export des structures
  + Inclure des énoncés "DROP TABLE"
  + Ajouter "IF NOT EXISTS"
  + Inclure la valeur courante de l'AUTO_INCREMENT
  + Protéger les noms des tables et des champs par des "`"
  + Inclure sous forme de commentaires
       * Dates de création/modification/vérification
- Compatibilité de l'exportation:  ANSI/DB2/MAXDB/MSSQL/MYSQL323/MYSQL40/ORACLE/POSTGRESQL/TRADITIONAL
- Données:
   + Insertions complètes
   + Insertions étendues
   + Insertions avec délais (DELAYED)
   + Ignorer les erreurs de doublons (INSERT IGNORE)
   + Encoder les champs binaires en hexadécimal
- Type d'exportation: INSERT/UPDATE/REPLACE
puis un import..  
 

ouais, mais ça reste un export au format SQL donc :
- problèmes de syntaxe avec les différentes versions (même s'il y a très peu de risque)
- problème de taille (même en zippant, ça restera plus gros qu'un fichier binaire compressé
- problème de lenteur pour générer le fichier et l'importer ensuite
 
c'est pour ça qu'utiliser l'éventuel outils de backup/restore me semble bien mieux.
 
à la limite, mais ça c'est goret, démonter les fichiers de la base, les récupérer puis les remonter.
on n'a plus qu'à mettre les fichiers sur le serveur cible et monter les fichiers dans une nouvelle base. mais cela implique d'avoir la même version du SGBD et le même paramétrage, donc le backup/restore reste une meilleure solution.

Avec mysql, t'as les requettes de type "load data infile" et "SELECT * INTO OUTFILE "nomdufichier.data" FROM ..." pour sauver et recharger les données.
Par contre, ca ne sauve pas la structure de la table et au rechargement gace au "load data", mysql (du moins en 5.0) va partir en répération de table pour générer les index. Sur une table de plusieurs giga, ca peut prendre un temps fous de réparer les index. L'avantage de cette méthode, c'est que le chargement des données est super rapide s'il n'y a pas d'index à réparer.

d'un autre côté, les index sont toujours plus rapide à mettre à jour si on les recrée à la fin plutôt que de les mettre à jour à chaque ligne insérée.
 
Ceci dit, je ne vois passer que des solutions bourrin là... Y'a pas de module "propre" de backup pour MySQL ???
 
Comment on fait quand on a des tables gigantesques (milliards de lignes) ? On doit mettre down la base pendant 6 heures tous les jours le temps de générer les 50 To de données dans des fichiers SQL, ou si y'a moyen de faire de l'incrémentiel proprement dans des fichiers de backup ???
 
Je parle de ça quoi (SQL Server 2005 Express Edition) :

 

 
Ca permet quand même de faire un truc vachement plus propre, rapidement, et surtout, pour des gros volumes, de faire du différentiel...

MagicBuzz > Pour ce que j'ai pu voir quand on a du recharger la table de 12 Go, quand on utilise un "load data infile" mysql ne mettra pas plus de temps à recréer les index que si on charge le fichier dans une table sans index et qu'on les rajoute ensuite.
En fait, dans ce genre de cas, il vaut mieux que les index existent dés le départ, ca évitera à mysql de dupliquer les données le temps de faire la "réparation des index".
 
Pour les tables de 50To, je suis pas sur que mysql soit la meilleure base quand on atteint ce genre de taille. D'ailleur, j'ignore s'il existe un systéme de sauvegarde incrémentale ou différentielle pour mysql et en fait, j'aurais tendance à dire que ca ne doit pas encore exister, du moins dans un mysql standard.