Question de fond reprise de données

[iviewclear]

Bonsoir

Je dois envisager la reprise d'une base PostGres vers une autre base PostGres.

J'ai à peu près les mêmes tables d'un côté comme de l'autre.

Mais là n'est pas mon souci.

J'essaye d'être clair :
Dans ma base de réception (Base A), j'ai évidemment des clés primaires et étrangères.
Dans ma base source (Base B), idem.

Quelle serait aujourd'hui une technique éprouvée afin de renuméroter les Id de mes tables contenues dans ma Base B afin qu' ils n'entrent pas en conflit avec ceux contenus dans les tables de ma Base A ?

Je n'attends évidemment pas une réponse parfaite à ma question mais au moins quelques pistes à approfondir.
Je ne suis pas DBA, j'ai quelques notions de SQL.

Je suis en train d'analyser ce que je dois reprendre table par table, d'analyser les structures des tables, etc....

Merci de votre aide précieuse

[CinePhil]

Y a t-il des données existantes communes aux deux BDD ?

Quand on fait ce genre de choses, on commence par les tables qui n'ont pas de clé étrangère et on ajoute les lignes de B inexistantes dans les tables de A.

Exemple avec une table de catégories (cat_id, cat_libelle)
Dans ce type de table, en plus de l'identifiant qui est par défaut unique, il est fort logiquement probable que le cat_libelle le soit aussi.
On peut donc faire cette requête pour importer les catégories de B qui ne sont pas dans A :

Code :

1
2
3
4
5
6
7
8
9
INSERT INTO a.categorie (cat_libelle)
SELECT cat_libelle 
FROM b.categorie
WHERE NOT EXIST (
  SELECT *
  FROM a.categorie
  WHERE a.categorie.cat_libelle = b.categorie.cat_libelle
)
ORDER BY b.cat_libelle

Je suppose bien sûr ici que l'identifiant est incrémenté par une séquence.

Ensuite si on a par exemple une table de produits qui a comme clé étrangère l'identifiant de la catégorie à laquelle il appartient, il faut faire la jointure sur le libellé pour affecter le nouvel identifiant de catégorie.

Une requête de sélection pour vérifier :

Code :

1
2
3
4
5
6
7
SELECT p.prd_id, p.prd_nom, 
  c1.cat_nom AS ancienne categorie,
  c2.cat_nom AS nouvelle_categorie,
  c2.cat_id
FROM b.produit p
INNER JOIN b.categorie c1 ON c1.cat_id = p.prd_id_categorie
  INNER JOIN a.categorie c2 ON c2.cat_nom = c1.cat_nom

Et il suffit de la transformer un peu et de l'utiliser dans une requête d'insertion des nouveaux produits, sur le même principe que précédemment en cherchant l'ensemble de colonnes de la table source, hors identifiant, qui peuvent distinguer de manière unique une ligne de la table, autrement dit trouver une clé alternative à la clé primaire de la table.

[iviewclear]

Bonjour et merci

Envoyé par CinePhil

Y a t-il des données existantes communes aux deux BDD ?

Quand tu dis "existante", tu sous-entends les mêmes valeurs dans les champs style clés primaires ?

Quand on fait ce genre de choses, on commence par les tables qui n'ont pas de clé étrangère et on ajoute les lignes de B inexistantes dans les tables de A.

Ca je comprends ok je vais regarder si c'est le cas, mais pas sur ce serait trop simple.

Exemple avec une table de catégories (cat_id, cat_libelle)
Dans ce type de table, en plus de l'identifiant qui est par défaut unique, il est fort logiquement probable que le cat_libelle le soit aussi.
On peut donc faire cette requête pour importer les catégories de B qui ne sont pas dans A :

Code :

Je suppose bien sûr ici que l'identifiant est incrémenté par une séquence.

Pour te répondre oui les id sont incrémentés par une séquence, je crois un truc du style nextval()

Ensuite si on a par exemple une table de produits qui a comme clé étrangère l'identifiant de la catégorie à laquelle il appartient, il faut faire la jointure sur le libellé pour affecter le nouvel identifiant de catégorie.

Une requête de sélection pour vérifier :

Code :

Et il suffit de la transformer un peu et de l'utiliser dans une requête d'insertion des nouveaux produits, sur le même principe que précédemment en cherchant l'ensemble de colonnes de la table source, hors identifiant, qui peuvent distinguer de manière unique une ligne de la table, autrement dit trouver une clé alternative à la clé primaire de la table.

Oula là ça se gate un peu....

Je reviendrai poster un exemple concret pour essayer d'u voir plus clair.
Et travailler avec une table de correspondance n'est-il pas un bon moyen ?

Merci