Pour avoir bossé dans une entité parapublique (les pires) où les assurés étaient dans plusieurs bases, sans point de vérité unique, j'ai vu le chaos informatique que ça générait. Je parle de tables où des gens pouvaient avoir 2 numéros de Sécu différents. (OK, dans ce milieu il y a parfois des cas vraiment tordus.)
Bizarrement, les assurés se plaignaient en permanence des erreurs.
La cause principale tenait plus du contexte interne assez shadokien et dilbertien.
Si l'on ne peut avoir de point de vérité unique, le minimum est la recherche agressive et systématique des erreurs et duplicas.
Des requêtes de comparaison, ça s'écrit. Mais il faut ensuite traiter ces doublons, manuellement souvent.
J'ai bossé dans les datawarehouses, où il faut rapprocher des sources parfois assez hétérogènes.
Avec du bol, entre deux application historiques, il y a une clé commune (N° de sécu d'un assuré…) mais il faut aussi une règle qui dit quelle base fait foi (où doit-on entrer un changement d'adresse ?) et ignorer le reste.
Autre exemple purement technique, d'un point de vue de DBA :
deux bases de données indépendantes et identiques se répliquent par triggers
(une base multimaître sur un SGBD qui ne le supporte pas nativement) : ça marche, jusqu'au jour où il y a un bug.
Et là, « split brain » et besoin de réconcilier les données.
Pas de possibilité d'effacer une partie et de recommencer.
Quand il n'y a qu'une source de données, comme tout devient simple !
(Même si on revient sur un souci d'invalidation du cache, ce qui est un autre sujet, mais purement technique.
Au moins, les techs n'ont pas besoin de déranger des fonctionnels.)
