Comment savoir s'il faut créer une vue ou migrer vers une table fusionnée ?

[Larry.L]

Je suis en train de refondre une petite application interne pour mon équipe et je me retrouve avec deux jeux de données assez similaires, mais pas identiques, que je dois fusionner. J'ai écrit un script pour tout mettre dans une nouvelle table, mais je me demande si je n'aurais pas dû plutôt créer une vue pour lier les anciennes tables sans toucher aux données existantes. J'ai un peu peur de me lancer dans une migration de données et de créer des incohérences sans m'en rendre compte. Certains d'entre vous ont-ils déjà été dans cette situation de devoir consolider des sources ?

[DonaldHP]

J ai été dans le cas de deux jeux de données qui ne collaient pas tout a fait et j ai ressenti un mélange d espoir et d inquietude. Une vue peut sembler simple mais elle ne règle pas les incohérences si elles existent deja dans les colonnes ou les règles de gestion. Ce qui aide c est de cartographier les divergences et de faire un petit test en lecture sur une copie pour observer ce que donne la fusion de données sans toucher a la source.

[Joseph_G]

Sur le fond les choix se jouent sur la nature du changement et sur les risques. La vue lie les anciennes tables sans toucher les donnees ce qui limite les risques de perte mais peut aussi masquer des divergences et compliquer les mises a jour de la logique. Une migration progressive permet de valider les lignes de regle et d assurer l integrite et elle facilite les audits mais elle requiert plus de discipline et de tests. Dans tous les cas la fusion de donnees est la clé pour parler la meme langue entre les sources.

[GraceOM]

Pour etre franc une vue ne resout pas tout dans une consolidation de sources et des performances peuvent devenir un drag si l on y accole des joints lourds. La question est aussi ce qui se passe quand une requete critique devient lente a cause de la fusion de donnees et des verifications referentielles au vol. Tu as deja pense a un plan de test de performance sur un jeu reduit pour mesurer l impact.

[Riley96]

Reformulons le souci comme ceci l enjeu n est pas de decider entre vue ou migration mais de clarifier comment chaque source est definie et comment on garantira une interpretation unique des donnees au moment de leur etendue dans l application. En d autres termes la question porte sur l agreement des modeles et la gestion des identifiants et de la synchronisation entre les sources lors de la fusion de donnees.

[Paisley.J]

Option prudente je me dirigerais vers une vue des que le besoin de modification a chaque etape est faible et que les performances tiennent le coup et que le risque de divergences est faible ce qui permet la fusion de donnees sans toucher a l historique.

[GeorgeJL]

Une approche hybride peut aussi fonctionner on coupera en deux phases une fase de comparaison de donnees entre les sources puis une migration progressive en verifiant chaque epingle de precision ce qui reduit aussi le risque de conflit lors de la fusion de donnees