From: | Thomas Boussekey <thomas(dot)boussekey(at)gmail(dot)com> |
---|---|
To: | Nabil Servais <nabil(dot)servais(at)gmail(dot)com> |
Cc: | pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org> |
Subject: | Re: [pgsql-fr-generale] Restauration de dump dans un nouveau schéma |
Date: | 2013-02-12 16:21:21 |
Message-ID: | CALUeYme5+NoTUmxY9k=aE9fK=BojCuJQxYDm-Hm=QMfM-86sEg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Bonjour Nabil,
Tout dépend de la volumétrie de données concernée, une solution simple
serait d'utiliser pg_dump avec l'option --inserts en format plain text pour
disposer d'un fichier SQL exploitable dans lequel il est possible de
récupérer les éléments à reprendre (Scripts de création d'objet et scripts
d'insertion des données).
-- Thomas
Le 12 février 2013 16:28, Nabil Servais <nabil(dot)servais(at)gmail(dot)com> a écrit :
> Bonjour à tous,
>
> Dans le cadre d'une migration de notre application métier, nous avons
> légèrement modifié notre schéma de base de données.
> Nos procédures imposent que le schéma de la base est créé par notre
> application métier et nous insérons les données via la restauration d'un
> dump.
> Certaines tables et séquences n'existant plus, cela a comme conséquence de
> provoquer des erreurs lors de la restauration de nos dumps et d'avoir une
> base incomplète.
>
> Ma question est comment récupéré les données sans polluer la base de
> données avec l'ancien schéma?
>
> Et de manière plus large, comment gérer les dumps et restauration des
> données d'une base de données dont le schéma peut être amené à changer?
>
>
> Merci à tous pour vos réponses.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-02-12 16:24:31 | Re: Restauration de dump dans un nouveau schéma |
Previous Message | Nabil Servais | 2013-02-12 15:28:41 | Restauration de dump dans un nouveau schéma |