par
Cyrano » 29 août 2008, 07:57
Le SQL est un langage, le CSV est une structure, on ne convertit pas de l'un vers l'autre.
Ton fichier SQL contient des requête. Un fichier de cette taille ne peut être exécuté qu'en ligne de commande. Si tu es en local, ça ne devrait pas poser de problème, mais sur un serveur distant, il va falloir commencer par uploader le fichier via FTP sur le serveur et avoir un accès à un utilitaire pour exécuter MySQL en ligne de commande.
Tu pourrais alors envisager de faire ton exportation directement en CSV avec une requête du genre "SELECT * INTO OUTFILE 'nom_du_fichier.csv' export_options"
Extrait de
la doc :
La forme SELECT ... INTO OUTFILE 'nom_fichier' de SELECT écrit les lignes sélectionnées dans un fichier. Le fichier est crée sur le serveur et ne peut y être déjà présent (cela permet entre autre d'éviter la destruction des tables et de fichiers tel que /etc/passwd). Vous devez avoir le droit FILE sur le serveur pour utiliser cette forme de SELECT.
SELECT ... INTO OUTFILE à pour but principal de vous permettre de réaliser des dumps rapides des tables sur la machine serveur. Si vous voulez créer le fichier sur une autre machine, vous ne pouvez utiliser SELECT ... INTO OUTFILE. Dans ce cas là, vous pouvez utiliser à la place un programme client comme mysqldump --tab ou mysql -e "SELECT ..." > fichier pour générer le fichier.
SELECT ... INTO OUTFILE est le complément de LOAD DATA INFILE; La syntaxe pour la partie export_options de la requête se compose des mêmes clauses FIELDS et LINES que celles utilisées avec la commande LOAD DATA INFILE.
Voir Section 13.1.5, « Syntaxe de LOAD DATA INFILE ».
Dans le fichier résultant, seul les caractères suivants sont protégés par le caractère ESCAPED BY :
- Le caractère ESCAPED BY
- Les premier caractère de FIELDS TERMINATED BY
- Les premier caractère de LINES TERMINATED BY
- ASCII 0 est convertit en ESCAPED BY suivi de 0 (ASCII 48).
Si le caractère FIELDS ESCAPED BY est vide, aucun caractère n'est protégé, et NULL vaut NULL, et non \N. Il est probable que ce ne soit pas une bonne idée de spécifier un caractère de protection vide, en particulier sir les valeurs de vos champs peuvent être n'importe quoi.
La raison de ce qui précède est que vous devez impérativement protéger chaque caractère FIELDS TERMINATED BY, ESCAPED BY, ou LINES TERMINATED BY pour assurer une relecture fiable du fichier. Le caractère ASCII 0 est échappé pour assurer la lisibilité sur certains clients.
Comme le fichier résultant ne se doit pas d'être syntaxiquement conforme à SQL, vous n'avez besoin d'échapper rien d'autre.
Voila un exemple de relecture de fichier au format utilisé par plusieurs anciens programmes.
Code : Tout sélectionner
SELECT a,b,a+b INTO OUTFILE '/tmp/result.text'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM test_table;
Le SQL est un langage, le CSV est une structure, on ne convertit pas de l'un vers l'autre.
Ton fichier SQL contient des requête. Un fichier de cette taille ne peut être exécuté qu'en ligne de commande. Si tu es en local, ça ne devrait pas poser de problème, mais sur un serveur distant, il va falloir commencer par uploader le fichier via FTP sur le serveur et avoir un accès à un utilitaire pour exécuter MySQL en ligne de commande.
Tu pourrais alors envisager de faire ton exportation directement en CSV avec une requête du genre "SELECT * INTO OUTFILE 'nom_du_fichier.csv' export_options"
Extrait de [url=http://dev.mysql.com/doc/refman/5.0/fr/select.html]la doc[/url] :
[quote]La forme SELECT ... INTO OUTFILE 'nom_fichier' de SELECT écrit les lignes sélectionnées dans un fichier. Le fichier est crée sur le serveur et ne peut y être déjà présent (cela permet entre autre d'éviter la destruction des tables et de fichiers tel que /etc/passwd). Vous devez avoir le droit FILE sur le serveur pour utiliser cette forme de SELECT.
SELECT ... INTO OUTFILE à pour but principal de vous permettre de réaliser des dumps rapides des tables sur la machine serveur. Si vous voulez créer le fichier sur une autre machine, vous ne pouvez utiliser SELECT ... INTO OUTFILE. Dans ce cas là, vous pouvez utiliser à la place un programme client comme mysqldump --tab ou mysql -e "SELECT ..." > fichier pour générer le fichier.
SELECT ... INTO OUTFILE est le complément de LOAD DATA INFILE; La syntaxe pour la partie export_options de la requête se compose des mêmes clauses FIELDS et LINES que celles utilisées avec la commande LOAD DATA INFILE. [url=http://dev.mysql.com/doc/refman/5.0/fr/load-data.html]Voir Section 13.1.5, « Syntaxe de LOAD DATA INFILE »[/url].
Dans le fichier résultant, seul les caractères suivants sont protégés par le caractère ESCAPED BY :
[list]
[*]Le caractère ESCAPED BY
[*]Les premier caractère de FIELDS TERMINATED BY
[*]Les premier caractère de LINES TERMINATED BY
[*]ASCII 0 est convertit en ESCAPED BY suivi de 0 (ASCII 48).[/list]
Si le caractère FIELDS ESCAPED BY est vide, aucun caractère n'est protégé, et NULL vaut NULL, et non \N. Il est probable que ce ne soit pas une bonne idée de spécifier un caractère de protection vide, en particulier sir les valeurs de vos champs peuvent être n'importe quoi.
La raison de ce qui précède est que vous devez impérativement protéger chaque caractère FIELDS TERMINATED BY, ESCAPED BY, ou LINES TERMINATED BY pour assurer une relecture fiable du fichier. Le caractère ASCII 0 est échappé pour assurer la lisibilité sur certains clients.
Comme le fichier résultant ne se doit pas d'être syntaxiquement conforme à SQL, vous n'avez besoin d'échapper rien d'autre.
Voila un exemple de relecture de fichier au format utilisé par plusieurs anciens programmes.
[code]SELECT a,b,a+b INTO OUTFILE '/tmp/result.text'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM test_table;[/code]
[/quote]
