Using GlobalID for a Relationship

[nataliejones1]

I have a feature class and a documents table to store the related documents.  I want to create a relationship between them and was thinking of using the GlobalID. With a lookup table holding the globalIDs of both.  Is it ok to use the GlobalID for this purpose or is it like the ObjectID and liable to change?

Any advice appreciated.

[JacquelinePursell]

Yes, I do know that.  

This is not for some random day when I want to change the IDs for fun.  This is for when I want to do a cold swap of a feature but keep the attribute table and the relationships intact.  There are so many times in my career when I have had to replace hundreds or thousands of bad shapes for better shapes and because all the databases I've ever encountered had a  straightforward user created ID, I was able to preserve this information and swap them out seamlessly.  The usage of the GlobalID for a relationship worried me on being able to do this, just like if I used the ObjectID.

Unfortunately I need to edit offline with this database and there will be 2+ users at a time in the field and some of them contractors. The GlobalID is so easy to use when editing offline because of the random nature and no user prompt but I really did not want to use it.  If I didn't use a Global ID then I would have to create a very intense and complicated stored procedure/trigger that would create the sequential ID I want offline.  I don't have the skills for that and we don't have enough money for it either to send it out.

I'm not sure what kind of "warranty" you are implying...  If the GlobalID was untouched and it made a hideous error and destroyed all the data in my database, do you really think ESRI would guarantee to restore it?  no, I don't think so.  I'm not altering their stored procedures. Also, in ESRI's own help documents is all kinds of backend manipulation of the GlobalID:  

Inserting a value into a global ID or GUID column in SQL Server using SQL—Help | ArcGIS for Desktop 

and...

Next_GlobalID—Help | ArcGIS for Desktop 

[VinceAngelo]

There are, of course, few warranties in the software world, and collisions in 128-bit space are possible,

but very remote.  I'm just pointing out that they're less remote (by many orders of magnitude) if you are

assigning values using two different algorithms (the examples you referenced use the same algorithm

that ArcGIS uses, so they're not likely to conflict).

If this is the only way to meet your requirement, so be it.  But I do urge caution (and a UNIQUE index

and robust error handling during assignment)

- V

[JacquelinePursell]

If I could create my own unique index that could do multiple offline devices then I would not feel the need to worry about altering a global ID.  I do not have the skills and we don't have the money to hire anyone out for it.  I would be more than fine using a user created ID too but we are shifting towards using more contractors to collect data and relying on random people to stay unique isn't possible.  Using the GlobalID feels like I'm giving up because it's just too easy to use. 

At least the scenario I outlined earlier about cold swapping out features is a rare event and it will never be me picking out some random ID, it will always be reusing the old ID to keep the relationships intact.  At least the ESRI GlobalID trigger only occurs upon an insert of a new record and I am just updating a record so there is no conflicts there either.

But if you or anyone else has an actual stored procedure built that does what I need, please share it!  Even if it was not for SQL Server, it can be easily modified.

[MaximeDemers]

I have read all this post. It was very interesting.

To summarize:

• GlobalId: Easy to Use but less performant because of inefficient indexing. There is also a limitation when you need to delete and re-insert a feature. The relationships will be lost.
• GUID: Same as GlobalId except that you have to create it yourself somehow. However the relationships are not lost when you delete and re-insert a feature.
• A sequential Id: Efficient index. You need to manage it yourself. Risk of loosing uniqueness especially when created on client side or offline.

Am I correct? Is there something to correct or to add?

Thank you