J'ai toujours évité d'utiliser des ObjectID lors de la définition des classes de relations. Je crois comprendre que certaines actions sur une géodatabase redéfiniront les ID d'objet (comme l'importation / exportation). Cependant, je vois beaucoup de gens les utiliser.
Suis-je simplement paranoïaque, ou existe-t-il des cas où il est sûr d'utiliser des ObjectID lors de la définition d'une classe de relations?
Réponses:
Les ID d'objet ne sont gérés que par Copier / Coller. Aucun outil d'importation ou d'exportation ne les maintient. Il n'est généralement pas recommandé d'utiliser des ObjectID dans les classes de relations. Si toutes vos données sont vraiment statiques, cela devrait fonctionner correctement, mais il y aura toujours un risque lorsque vous importez ou exportez les données.
Dans la mesure du possible, je fonde les relations sur d'autres domaines clés. L'utilisation d'ObjectID m'a posé des problèmes dans le passé pour les raisons exactes mentionnées par Lance. Dans les projets où les données qui sont transférées dans les deux sens entre notre serveur SDE et un serveur client, l'utilisation de l'ObjectID pour relier les tables signifie avoir à effectuer diverses opérations sur les tables pour maintenir les relations.
Même s'il n'est pas prévu de déplacer les données, je préfère toujours utiliser un champ différent pour les clés. D'après mon expérience, les clients ne comprennent généralement pas pleinement les implications de leurs actions sur les bases de données SIG et cassent souvent les choses sans s'en rendre compte. J'ai eu des cas où les clients déplacent des données de manière à modifier l'ObjectID. Mes projets impliquent généralement un code personnalisé pour accompagner la base de données et je n'aime pas compter sur la compréhension du système par les clients pour éviter les pannes. Donc, je préfère de loin utiliser d'autres champs pour les clés primaires et pour les relations, champs que je peux contrôler.