I have a feature class of our Sign Posts and a table of Signs. The signs are related to the SignPosts. I was struggling with trying to update a unique ID in Web AppBuilder so I contacted ESRI. I was looking at a trigger in ArcSDE, but ESRI support told me that that is not supported. The ESRI support Analyst said, why not use the ObjectID? I always thought this was not encouraged because ObjectIDs can change when exporting.
Is this a change in thinking from ESRI or was my understanding wrong all along? What are the downsides of using the ObjectID other than the export issues?
Using the ObjectID certainly makes life easier for me, but was surprised to hear ESRI suggest this.
Well, I personally have used the ObjectID field (for the feature class) and a self-created ID field (for the related table) without any problem as off now.
If the ObjectID of the feature changes in the feature class, it should automatically make that change in the related table too.
Test it out and check if it suits you.
Coming to think of it, the ObjectID of the feature class will not change unless doing an Import\Export, in which case you will have to rebuilt the Relationship Class and everything can be a mess. So as long as your Feature class is going to stay in the same gdb or you can use Copy\Paste to transfer data, using ObjectIDs should work fine. Otherwise it may not be the optimal solution for everyone.
I "kind of" use the object id as a unique identifier for relationships; For streets and their respective alternate names I have a field called JoinID. In the streets feature class I calc the JoinID to equal the OID. That way I know it's always unique, and it persists no matter what I do with the data. My alternate names table is designed to capture corresponding value in its JoinID field.
I was thinking of this approach as well. Let ArcSDE create the ObjectID and than duplicate it in a different "ID" field so that it stays original.
Thanks for sharing your approach.