Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Shop Recherche
1797 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Importer une base de données

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Importer une base de données

n°1445118
johnson951
Posté le 20-09-2006 à 11:26:35  profilanswer
 

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

mood
Publicité
Posté le 20-09-2006 à 11:26:35  profilanswer
 

n°1445130
bastoonet2​3
pouet !
Posté le 20-09-2006 à 11:36:39  profilanswer
 

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.

n°1445278
johnson951
Posté le 20-09-2006 à 13:44:11  profilanswer
 

Merci je vais voir cela tout de suite !

n°1445282
chani_t
From Dune
Posté le 20-09-2006 à 13:48:01  profilanswer
 

bastoonet23 a écrit :

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.


+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).

n°1447173
MagicBuzz
Posté le 25-09-2006 à 15:21:18  profilanswer
 

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..

Message cité 1 fois
Message édité par MagicBuzz le 25-09-2006 à 15:21:30
n°1447199
chani_t
From Dune
Posté le 25-09-2006 à 16:21:13  profilanswer
 

MagicBuzz a écrit :

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..  
 
:D

n°1447203
MagicBuzz
Posté le 25-09-2006 à 16:33:54  profilanswer
 

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.

n°1447227
omega2
Posté le 25-09-2006 à 17:13:08  profilanswer
 

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.

n°1447287
MagicBuzz
Posté le 25-09-2006 à 19:38:52  profilanswer
 

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) :
http://www.manga-torii.com/files/backup.png
 
http://www.manga-torii.com/files/restore.png
 
Ca permet quand même de faire un truc vachement plus propre, rapidement, et surtout, pour des gros volumes, de faire du différentiel...

n°1447407
omega2
Posté le 26-09-2006 à 09:31:59  profilanswer
 

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.


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Importer une base de données

 

Sujets relatifs
Problème ligne de base CSS -> IE et Firefox différents ...base de données et dreamweaver
Donnees en colonnes dans le header excel%userProfile% dans la base de registre......
VB ou C# mode graph Pour attaquer une Base MySQL ?[RESOLU][MYSQL] Importer une base de données
importer données d'une base MySQL dans une autre..Help[ACCESS] Importer dans une base les données de plusieurs bases Access
Importer un fichier *.txt dans une base de données Access 2000[Delphi] importer un fichier .xls dans une base de données
Plus de sujets relatifs à : Importer une base de données


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR