Comment fusionner deux jeux de données similaires sans perdre la traçabilité?

[Tyler.M]

Je suis en train de refondre une petite application interne pour mon équipe et je me retrouve avec deux ensembles de données très similaires, mais provenant de sources historiques différentes. J’ai l’impression que je devrais les fusionner dans une seule table pour simplifier les requêtes, mais en même temps, garder les sources séparées faciliterait le traçage d’une éventuelle anomalie. Je ne sais pas trop quelle approche adopter pour ce schéma de base de données, c’est un choix qui me paraît plus important que prévu et je tourne un peu en rond.

[Ryan_M]

Pour fusionner ou non, commence par écrire les exigences réelles: traçabilité des sources, performance des requêtes et évolutivité du schéma. Une voie consiste à fusionner les deux jeux dans une table unique mais avec des marqueurs explicites: source_id, version, et une colonne valid_from et valid_to ou une colonne date. Cela permet d’écrire des requêtes simples tout en conservant une piste d’audit. Attention: si les champs diffèrent entre les sources, il faut harmoniser les types et les valeurs, et prévoir des règles de compatibilité. En pratique, vous pourriez opter pour une table centrale avec un champ source_id et, si nécessaire, une table de référence des sources. Si vous fusionnez, vous gagnez en simplicité, mais l’audit et la traçabilité deviendront des garanties du schéma et nécessiteront des garanties supplémentaires.

[Paul70]

J’éviterais de tout fusionner sans plan de traçabilité. Une table unique peut faciliter les requêtes, mais vous perdez une séparation claire des historiques et des sources, ce qui complique les vérifications d’anomalies. Mon conseil: garder les sources séparées mais exposer une vue ou une table de référence qui les unifie pour les requêtes courantes, et réserver le chemin par source pour les audits. On peut aussi ajouter une colonne source_hash et versioning. Fusionner tout sans couche d’audit peut devenir un piège.

[Donald.H]

Franchement, ça me stresse un peu l’idée de fusionner, j’ai peur de casser des historiques qui ne coïncident pas, et puis le moindre petit changement peut bouffer des dashboards. Je voudrais un middle ground: fusionner les données pour les rapports courants mais garder une piste d’audit prête à l’emploi. Le mot clé fusionner me paraît à la fois tentant et dangereux.

[MatthewA]

Si on reformule le problème, l’enjeu n’est pas seulement le schéma mais la façon dont on assure traçabilité et simplicité. Cherchez une approche hybride: gardez deux sources visibles mais exposez une couche unifiée pour les résultats fréquents. Par exemple, une table centrale avec les champs communs et une colonne source_id qui pointe vers des tables de métadonnées des sources, ainsi qu'une timeline. Ainsi, vous pouvez fusionner les données les jours où l’audit l’exige et revenir à une vue séparée quand on enquête.

[Madison_B]

fusionner peut simplifier les requêtes mais impose des règles claires de compatibilité et de versioning; démarrez par un modèle de données minimal et testez avec des requêtes réelles.

[Grace.W]

J’ai remarqué que certains veulent absolument une seule table pour ne plus écrire des joins. Mais quand on travaille sur des anomalies, on se retrouve vite à vérifier la source, les timestamps et les statuts. Une option courante est un modèle à deux couches: une table de faits fusionnés et une table de mapping source. En parallèle, on peut ajouter des index sur (source_id, id, version) et sur les colonnes de comparaison. Tant que vous n’écrasez pas les informations de provenance, le schéma peut rester flexible.

[Edward.T]

Et côté pratique, vous avez déjà une liste des champs qui diffèrent entre les deux sources et leur fréquence de divergence, pour savoir si la fusionner est envisageable ou non?