¿Cuándo es seguro usar ObjectID como claves en una clase de relación?

Siempre he evitado usar ObjectIDs al definir clases de relación. Tengo entendido que algunas acciones en una geodatabase restablecerán los ID de objeto (como importar / exportar). Sin embargo, veo mucha gente usándolos.

¿Estoy siendo paranoico o hay casos en los que es seguro usar ObjectID al definir una clase de relación?

Los ObjectID solo se mantienen mediante Copiar / Pegar. Ninguna herramienta de importación o exportación los mantiene. Por lo general, no se recomienda usar ObjectIDs en clases de relación. Si todos sus datos son verdaderamente estáticos, debería funcionar bien, pero siempre habrá un riesgo cuando importe o exporte los datos.

Siempre que sea posible, baso las relaciones en otros campos clave. El uso de ObjectID me ha presentado problemas en el pasado por las razones exactas mencionadas por Lance. En proyectos donde los datos que se transfieren de un lado a otro entre nuestro servidor SDE y un servidor de clientes, usar el ObjectID para relacionar tablas significa tener que realizar varias maquinaciones en las tablas para mantener las relaciones.

Incluso si no hay un plan para mover los datos, prefiero usar un campo diferente para las claves. Mi experiencia es que los clientes generalmente no entienden completamente las implicaciones de sus acciones en las bases de datos SIG y, a menudo, rompen las cosas sin darse cuenta. He tenido casos en los que los clientes mueven datos de formas que alteran el ObjectID. Por lo general, mis proyectos involucran un código personalizado que acompaña a la base de datos y no me gusta confiar en que los clientes comprendan el sistema para evitar fallas. Por lo tanto, prefiero usar otros campos para claves principales y para relaciones, campos que puedo controlar.