Bonjour,
En matière de modélisation et de maintien opérationnel au cours du temps, choisir l’attribut d’un objet pour lui attribuer une ID unique est une très mauvaise pratique, et pour avoir parcouru rapidement ce fil, l’exemple code insee est révélateur. Utilisez un identifiant unique de type numérique généré par le système (typiquement un serial). Chaque objet créé est ainsi unique et ne fait pas dépendre l’objet (donc la logique du système) d’un de ses attributs susceptible d’évoluer au gré du producteur de la donnée, typiquement une administration. La fusion de commune est un exemple révélateur du choix « code insee ». voir ici :
Forum GeoRezo / utilisation comme référentiel pivot du code Insee des communes
C’est le principe du plus grand dénominateur commun. Chaque entité est unique selon Id_Entitie après attribut SIRET no data value n’est pas interdit …
Quelque chose comme cela

La répétition du Id_personne_morale est volontaire c’est pour forcer le trait sur le fait que c’est toujours la même chose sous une autre forme. C’est la magie du polymorphisme 
Sous l’angle base de données pour gérer les cas d’utilisations évoqués dans vos contributions, un objet géolocalisé qui peut évoluer au cours du temps, fusionner, se déplacer, être divisé ?

Ceci permet en matière de base de données de modéliser un graphe. C’est le cas il me semble pour vos cas d’utilisations non ?
Pour un exemple d’utilisation de graphe avec les bases de données :
Forum GeoRezo / Nouveauté Opendata : Cadastre, documents de filiation
Chaque personne morale possède au moins une image c’est la sienne.
A sa création elle a le statut de mère.
A chaque modification importante (fusion, déplacement etc …) un nouvel objet personne morale est créé en mode actif, il a le statut de fille, l’ascendant est désactivé mais persiste dans la base.
Une entrée est créée dans la table réflexive si l’ascendante était déjà une fille.
En matière d’intégration l’ajout d’un attribut « sourcededonnées » permet d’intégrer plusieurs sources dans la même base et d’utiliser SQL pour vérifier si l’objet est nouveau ou s’il existe déjà sur la base de règles métier, de type si mêmes siret, siren, géoloc alors même objet, donc inactivation et préservation des sources création d’une nouvelle entité active sources vérifiées sources X, Y Z.