[conceptuelle] Importation des données d'une application relationnelle existante -> co mment prévoir la migration de l'intégrité référentielle ?
1 réponse
Alomphega
Bonjour,
Soit une application écrite dans un SGBDR relationnel non SQL qui
fonctionne depuis longtemps, avec des clés primaires auto incrémentées
utilisées aussi comme références des données représentées par leurs
fiches (par exemple : "refProduit" pour les produits, "refFacture" pour
les factures, etc.)
Soit une nouvelle application réalisée de manière plus ouverte et
standard, destinée à récupérer les données de la précédente, les tables
étant identiques.
Comment concevoir les clés primaires pour la nouvelle application ?
J'ai pensé dans l'ordre :
1) construire les tables à l'identique sans auto incrémentation pour les
clés primaires
2) importer les données depuis l'ancienne application (chaque champ
ayant son correspondant) dans la nouvelle, les "ref" dans les champs des
clés primaires
3) attribuer l'auto incrémentation aux clés primaires après
l'importation pour assurer la continuation de l'intégrité référentielle
Mais je me demande si c'est le plus rationnel et si le fait d'attribuer
l'auto-incrément après l'import ne va pas effacer toutes les références
importées, aussi vos avis, liens et expériences me seront précieux.
Cordialement,
--
Guy AJ Capra
________________________
http://www.alomphega.com
http://www.openmeans.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alomphega
Le 22/11/2005 15:13, Patrick Mevzek inscrivait :
Le Tue, 22 Nov 2005 10:25:40 +0100, Alomphega a écrit :
Mais je me demande si c'est le plus rationnel et si le fait d'attribuer l'auto-incrément après l'import ne va pas effacer toutes les références importées, aussi vos avis, liens et expériences me seront précieux.
Avec PostgreSQL par exemple, qui utilise des séquences, un dump et reload (dans une autre base) ne pose pas de problème, car l'état de la séquence est sauvegardée et re-appliquée au moment du reload, donc la séquence part bien de là où elle s'était arretée.
Votre méthode est donc bonne, mais il faut voir les spécificités selon les SGBDR concernés.
Merci de votre retour. Le SGBDR en question est HSQLBD à http://hsqldb.org/
Cordialement, -- Guy AJ Capra ________________________ http://www.alomphega.com http://www.openmeans.org
Le 22/11/2005 15:13, Patrick Mevzek inscrivait :
Le Tue, 22 Nov 2005 10:25:40 +0100, Alomphega a écrit :
Mais je me demande si c'est le plus rationnel et si le fait d'attribuer
l'auto-incrément après l'import ne va pas effacer toutes les références
importées, aussi vos avis, liens et expériences me seront précieux.
Avec PostgreSQL par exemple, qui utilise des séquences, un dump et reload
(dans une autre base) ne pose pas de problème, car l'état de la
séquence est sauvegardée et re-appliquée au moment du reload, donc la
séquence part bien de là où elle s'était arretée.
Votre méthode est donc bonne, mais il faut voir les spécificités selon
les SGBDR concernés.
Merci de votre retour.
Le SGBDR en question est HSQLBD à http://hsqldb.org/
Cordialement,
--
Guy AJ Capra
________________________
http://www.alomphega.com
http://www.openmeans.org
Le Tue, 22 Nov 2005 10:25:40 +0100, Alomphega a écrit :
Mais je me demande si c'est le plus rationnel et si le fait d'attribuer l'auto-incrément après l'import ne va pas effacer toutes les références importées, aussi vos avis, liens et expériences me seront précieux.
Avec PostgreSQL par exemple, qui utilise des séquences, un dump et reload (dans une autre base) ne pose pas de problème, car l'état de la séquence est sauvegardée et re-appliquée au moment du reload, donc la séquence part bien de là où elle s'était arretée.
Votre méthode est donc bonne, mais il faut voir les spécificités selon les SGBDR concernés.
Merci de votre retour. Le SGBDR en question est HSQLBD à http://hsqldb.org/
Cordialement, -- Guy AJ Capra ________________________ http://www.alomphega.com http://www.openmeans.org
