Eu sempre evitei usar ObjectIDs ao definir classes de relacionamento. Entendo que algumas ações em um banco de dados geográfico redefinirão os IDs dos objetos (como importação / exportação). No entanto, vejo muitas pessoas usando-os.
Estou apenas sendo paranóico ou há casos em que é seguro usar ObjectIDs ao definir uma classe de relacionamento?
Respostas:
Os ObjectIDs são mantidos apenas por Copiar / Colar. Nenhuma ferramenta de importação ou exportação os mantém. Geralmente, não é recomendável usar os ObjectIDs nas classes de relacionamento. Se todos os seus dados forem realmente estáticos, eles deverão funcionar bem, mas sempre haverá um risco ao importar ou exportar os dados.
Sempre que possível, baseio os relacionamentos em outros campos-chave. O uso do ObjectID apresentou problemas para mim no passado pelas razões exatas mencionadas por Lance. Nos projetos em que os dados são transferidos entre o servidor SDE e o servidor de clientes, o uso do ObjectID para tabelas relacionadas significa ter que executar várias maquinações nas tabelas para manter relacionamentos.
Mesmo que não haja um plano para mover os dados, ainda prefiro usar um campo diferente para as chaves. Minha experiência é que os clientes geralmente não entendem completamente as implicações de suas ações nos bancos de dados GIS e geralmente quebram as coisas sem perceber. Eu tive casos em que clientes movem dados de maneiras que alteram o ObjectID. Meus projetos geralmente envolvem algum código personalizado para acompanhar o banco de dados e não gosto de confiar no entendimento do cliente do sistema para evitar falhas. Portanto, prefiro usar outros campos para chaves primárias e relacionamentos, campos que posso controlar.