Vous n'êtes pas identifié(e).
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 
Hors ligne
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@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
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
Bonjour dverite. Merci pour l'explication. Promis, je tâcherai de ne plus oublier le "s" à la fin de "personne"
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
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
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
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
Sympa, quelqu'un propose cette "fonction ?" qu'il a réalisée :
https://www.postgresql.org/message-id/9 … B524@eng02
Hors ligne
Bjr
dites moi svp vous utilisez quoi pour migrer vos données
MErci
Hors ligne