PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 14/12/2018 18:33:18

Yapounet
Membre

Migration simple vers PostgresSQL, problème de clés étrangères.

Bonjour.

J'ai un transfert relativement simple à faire de Oracle vers Postgres. Quelques tables, la base cible existe déjà, elle a exactement la même structure donc, à vue de nez, pas trop de problèmes.

Par contre, je me pose des questions sur les clés étrangères. Que se passe-t-il si on importe des données qui contrarient les clés étrangères tant que tout n'est pas importé ?
Par exemple :
CREATE TABLE personnes (
        code_personne text PRIMARY KEY,
        nom_personne text,
        responsable text REFERENCES personne (code_personne)
);
Cette table, en quelque sorte, pointe sur elle même. Selon l'ordre des données à importer, on peut avoir des soucis. En on peut même avoir des problèmes insolubles sir toto a pour responsable titi, et que titi a pour responsable toto (oui je sais, c'est capilotracté).
Une solution serait de suspendre les clés étrangères le temps de tout importer, puis de les réactiver ensuite. Mais est-ce possible ?

Que pouvez-vous me proposer ?

Attention, je suis un gros newbie. Je n'ai même jamais touché Postgres. J'ai cette étude à faire pour donner un coup de main à mon boss.
Merci d'avance smile

Hors ligne

#2 14/12/2018 19:06:32

dverite
Membre

Re : Migration simple vers PostgresSQL, problème de clés étrangères.

Ce n'est pas spécialement un problème de migration, avec une extraction postgres à recharger par postgres le problème est le même.

Si on crée la table ci-dessus avec PostgreSQL, modulo l'oubli de S à personneS,  et qu'on l'exporte avec pg_dump, il va éviter le problème d'intégrité référentielle en faisant ce découpage:

CREATE TABLE public.personnes (
    code_personne text NOT NULL,
    nom_personne text,
    responsable text
);

...

COPY public.personnes (code_personne, nom_personne, responsable) FROM stdin;
... ici les contenus...

... ensuite seulement l'ajout des contraintes

ALTER TABLE ONLY public.personnes
    ADD CONSTRAINT personnes_pkey PRIMARY KEY (code_personne);

ALTER TABLE ONLY public.personnes
    ADD CONSTRAINT personnes_responsable_fkey FOREIGN KEY (responsable) REFERENCES public.personnes(code_personne);

.. pour finir les droits d'accès via GRANT

Hors ligne

#3 14/12/2018 19:34:13

gleu
Administrateur

Re : Migration simple vers PostgresSQL, problème de clés étrangères.

Il est aussi possible de désactiver temporairement la clé étrangère. Pas spécialement recommandé ceci dit. Une autre solution serait de repousser la vérification de la contrainte à la fin de la transaction. Je ne me rappelle pas si c'est possible pour une clé étrangère ceci dit. À vérifier.


Guillaume.

Hors ligne

#4 14/12/2018 22:16:46

Yapounet
Membre

Re : Migration simple vers PostgresSQL, problème de clés étrangères.

Bonjour dverite. Merci pour l'explication. Promis, je tâcherai de ne plus oublier le "s" à la fin de "personne" smile
Mon problème avec ton explication, est que la base est déjà créée. Non seulement créée, mais en plus, je n'ai la main ni sur la structure des fichiers, ni sur les scripts de création.
Sinon, en effet, j'avais bien pensé à créer à part les scripts de contraintes comme je le faisais avant sur MSSql mais...


Bonjour gleu. Merci pour l'idée de désactiver temporairement les contraintes liées aux clés étrangères, c'est exactement ce que je cherche. Une idée de comment cela peut se faire ? Sinon je chercherai.
Sinon, repousser la vérification à la fin de la transaction est envisageable, si la transaction peut "encaisser" un import de toute la bdd qui est assez costaud. Pareil, si tu sais comment je suis partant, sinon je chercherai aussi.


Merci à tous. J'essaierai de faire un feedback.

Dernière modification par Yapounet (14/12/2018 22:17:36)

Hors ligne

#5 14/12/2018 23:05:42

gleu
Administrateur

Re : Migration simple vers PostgresSQL, problème de clés étrangères.

Avec un ALTER TABLE ... DISABLE TRIGGER (https://www.postgresql.org/docs/11/sql-altertable.html), les clés étrangères étant gérées en interne comme des triggers. Cette solution n'est pas la meilleure dans le sens où les données ne sont pas vérifiées lors de la réactivation.


Guillaume.

Hors ligne

#6 15/12/2018 10:11:23

Yapounet
Membre

Re : Migration simple vers PostgresSQL, problème de clés étrangères.

AH. Oui, c'est un souci qu'il n'y ait pas de vérification. Quoique, on peut penser que la base d'origine (Oracle à vue de nez) ait les mêmes contraintes, et que celles-ci sont respectées. Donc, finalement, je dirai qu'il n'y a pas de soucis sur ce point.


Par contre, pour détecter tous les triggers... je suppose qu'on peut parcourir certaines tables descriptives pour les trouver. Je proposerai cela à la personne qui m'a confié ce petit boulot.


Merci

Dernière modification par Yapounet (15/12/2018 10:13:52)

Hors ligne

#7 15/12/2018 10:56:14

Yapounet
Membre

Re : Migration simple vers PostgresSQL, problème de clés étrangères.

Ah bien. Un truc du genre (j'ai bien dit "du genre", je me renseignerai plus tard sur la syntaxe et ou trouver les listes de tables and co, je n'ai pas encore à ce jour touché de Postgres) :


Avant import :
For each NomDeTable in Liste_des_tables_de_ma_base_de_données
   ALTER TABLE NomDeTable DISABLE TRIGGER ALL
End Each


Après import :
For each NomDeTable in Liste_des_tables_de_ma_base_de_données
   ALTER TABLE NomDeTable ENABLE TRIGGER ALL
End Each


Super.
(Mais pourquoi doubler les sautes de lignes blanches pour avec une ligne blanche ? Ca vient de chez moi ou quoi ?)

Dernière modification par Yapounet (15/12/2018 10:57:22)

Hors ligne

#8 15/12/2018 11:03:56

Yapounet
Membre

Re : Migration simple vers PostgresSQL, problème de clés étrangères.

Sympa, quelqu'un propose cette "fonction ?" qu'il a réalisée :
https://www.postgresql.org/message-id/9 … B524@eng02

Hors ligne

Pied de page des forums