I've always avoided using ObjectIDs when defining relationship classes. It is my understanding that some actions on a geodatabase will re-set objectIDs (like import/export). However I do see a lot of people using them.
Am I just being paranoid, or are there cases when it is safe to use ObjectIDs when defining a relationship class?
ObjectIDs are only maintained by Copy/Paste. No import or export tool maintains them. It's generally not recommended to user ObjectIDs in relationship classes. If all of your data is truly static it should work ok, but there will always be a risk when you import or export the data.
Whenever possible I base relationships on other key fields. Using ObjectID has presented problems for me in the past for the exact reasons mentioned by Lance. In projects where data that is transfered back and forth between our SDE server and a clients server, using the ObjectID for relating tables means having to perform various machinations on the tables to maintain relationships.
Even if their is no plan to move the data, I still prefer using a different field for keys. My experience is that clients usually don't fully understand the implications of their actions on GIS databases and often break things without realizing it. I have had cases where clients move data around in ways that alter the ObjectID. My projects typically involve some custom code to go along with the database and I don't like relying on the clients understanding of the system to prevent failures. So, I much prefer using other fields for primary keys and for relationships, fields that I can control.
