Discussion :

[frocket]

Bonjour,

Je souhaiterai faire un backup de ma BDD (juste les data) en mettant les tables dans le bon ordre.
Je m'explique : si je fais un export avec phppgadmin (ou avec pg_dmp.exe), puis que je vide ma base, et importe le fichier créé lors de mes manips d'export, j'ai des erreurs de "violates foreign key constraint".

Je voudrais donc exporter automatiquement les tables dans "le bon ordre" en respectant les contraintes.

J'ose imaginer qu'il y a une solution, car modifier les .sql à la main c'est long ... mais surtout je ne sais pas quels mots clés rechercher en gros...

Voilà merci si quelqu'un peut m'éclairer.

a+

[kain_tn]

En principe, en utilisant pg_dump ou pg_restore, tu ne devrais pas avoir de problème particulier. Tu peux toujours jouer avec les différentes options...

[frocket]

En principe, en utilisant pg_dump ou pg_restore, tu ne devrais pas avoir de problème particulier. Tu peux toujours jouer avec les différentes options...

Justement pg_dump exporte les tables par ordre alphabétique.
Si la table "A" possède des clés étrangères situées dans la table "B", j'ai des erreurs.
Je vais voir du côté de pg_restore.
(Avant je restaurai via phppgadmin ou

Code :

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

"[...]psql.exe" -e -U myuser -d mybase -f data.sql

)

EDIT :
Après avoir essayé ceci :

Code :

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

1
2
3
"%PG_DIR%pg_dump.exe" -U myuser -Ft mybase > base.tar
 
"%PG_DIR%pg_restore.exe" -U myuser -d mybase base.tar

Toujours la même chose.

En regardant les options je ne trouve pas mon bonheur. Il doit y avoir une notion que je n'ai pas comprise ou complètement manquée !?
Ma façon de gérer les clé étrangère n'est peut-être pas bonne ?

[estofilo]

L'option -L de pg_restore permet de spécifier un ordre alternatif.

[frocket]

L'option -L de pg_restore permet de spécifier un ordre alternatif.

Merci. Je pourrai creuser cette piste, mais n'est-il pas possible d'ordonnancer lors du dump plutôt que lors du restore ?

[estofilo]

Je pense que pg_dump adopte un algorithme différent suivant qu'on spécifie l'option -a (--data-only) ou pas.
Au début de la discussion tu dis que tu veux sauvegarder uniquement les données (donc sous-entendu par les définitions des tables et les contraintes d'intégrité associées) donc j'imaginerais que c'est avec l'option -a.
Mais plus loin la commande pg_dump que tu cites n'a pas cette option.
Peux-tu préciser ça de manière explicite? -a ou pas -a ?

[frocket]

Je pense que pg_dump adopte un algorithme différent suivant qu'on spécifie l'option -a (--data-only) ou pas.
Au début de la discussion tu dis que tu veux sauvegarder uniquement les données (donc sous-entendu par les définitions des tables et les contraintes d'intégrité associées) donc j'imaginerais que c'est avec l'option -a.
Mais plus loin la commande pg_dump que tu cites n'a pas cette option.
Peux-tu préciser ça de manière explicite? -a ou pas -a ?

Au temps pour moi, à trop vouloir éclaircir mon code, j'en ai trop enlevé... Voici mon dump complet :

Code :

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

1
2
3
4
5
6
7
@echo off
set PG_DIR=C:\Program Files\PostgreSQL\8.3\bin\
set NEWDATE=%DATE:~0,2%-%DATE:~3,2%-%DATE:~6,4%_%TIME:~-11,-9%-%TIME:~-8,-6%-%TIME:~-5,-3%
 
"%PG_DIR%pg_dump.exe" --data-only --inserts --file=data-%NEWDATE%.sql --format=p --username=myuser mybase
 
pause

--data-only = -a, pour n'avoir que les données (je garde la structure via une autre fonction)
--inserts, pour avoir les sauvegarde en mode SQL et non pas COPY, si je ne dis pas de bêtises.

[estofilo]

OK ça explique que l'import des données ne passe pas directement, les contraintes d'intégrité n'étant pas du tout considérées par l'export dans ce contexte.
Pour ma part je pense qu'il n'y a pas de solution au niveau de l'export, sauf à le faire table par table avec l'option -t, mais ça parait plutôt moins pratique que d'agir à la restauration avec l'option -l

[frocket]

OK ça explique que l'import des données ne passe pas directement, les contraintes d'intégrité n'étant pas du tout considérées par l'export dans ce contexte.
Pour ma part je pense qu'il n'y a pas de solution au niveau de l'export, sauf à le faire table par table avec l'option -t, mais ça parait plutôt moins pratique que d'agir à la restauration avec l'option -l

Oui en fait j'ai fait en 2 temps en concaténant les dump...

Code :

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

1
2
3
4
set TABLE1=--table=A --table=Z
set TABLE2=--table=QuiDependDeA--table=QuiDependDeZ
"%PG_DIR%pg_dump.exe" --data-only --inserts %TABLE1% --format=p --username=myuser mybase  > %CURRENT_DIR%data-%NEWDATE%.sql
"%PG_DIR%pg_dump.exe" --data-only --inserts %TABLE2% --format=p --username=myuser mybase >> %CURRENT_DIR%data-%NEWDATE%.sql

[kain_tn]

Petite question au passage: pourquoi tu ne veux pas utiliser le mode COPY plutôt que INSERT? C'est bien plus rapide pour ré-injecter les données (sans comparaison avec le mode INSERT en termes de performances sur une grosse base)

La seule contrainte imposée dans ce cas est qu'il te faudrait faire ta restauration de base en ligne de commande et non sous phppgadmin.

Il est possible (de mémoire) que tu ne rencontre pas ton problème de clés étrangères avec le mode COPY

[SQLpro]

Le plus simple est de faire un script qui enlève les contraintes FK avant insertion et les remet après.
C'est assez facile à faire avec les vues normalisées d'information de schéma.
Inspirez vous de ce que j'ai fait pour SQL Server :
http://blog.developpez.com/sqlpro/p6...ts-sql-server/
En particulier des points 2 et 6

A +

[frocket]

Merci à vous deux.

En fait mon but était d'avoir un moyen simple de sauver une petite base. Et de pouvoir éventuellement ré-injecter les données via phppgadmin (voilà pourquoi INSERT plutôt que COPY).

Ma solution, bien qu'un peu moche, me suffit au final. Et je n'ai pas le temps de me consacrer à une autre solution pour l'instant...

Je mets le sujet en "résolu" ?