Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Migration » Migration simple vers PostgresSQL, problème de clés étrangères. » 15/12/2018 11:03:56
Sympa, quelqu'un propose cette "fonction ?" qu'il a réalisée :
https://www.postgresql.org/message-id/9 … B524@eng02
#2 Re : Migration » Migration simple vers PostgresSQL, problème de clés étrangères. » 15/12/2018 10:56:14
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 ?)
#3 Re : Migration » Migration simple vers PostgresSQL, problème de clés étrangères. » 15/12/2018 10:11:23
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
#4 Re : Migration » Migration simple vers PostgresSQL, problème de clés étrangères. » 14/12/2018 22:16:46
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.
#5 Migration » Migration simple vers PostgresSQL, problème de clés étrangères. » 14/12/2018 18:33:18
- Yapounet
- Réponses : 8
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
Pages : 1