Print Page | Close Window

Guid vs Integer IDs

Printed From: IdeaBlade
Category: Cocktail
Forum Name: Community Forum
Forum Discription: A professional application framework using Caliburn.Micro and DevForce
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3882
Printed Date: 20-Sep-2025 at 3:32am


Topic: Guid vs Integer IDs
Posted By: gregweb
Subject: Guid vs Integer IDs
Date Posted: 10-Jan-2013 at 3:53pm
One thing I notice that TempHire uses regularly is a Guid for the ID of an Entity as opposed to an int generated by SqlServer.

I have used both, but I tend to favor the int mainly due to the much smaller size, and thus, it's a lot faster to send over the wire.

For example, if you have a Contact with 10 phone numbers, the guids alone are the large part of sending the data over the wire. Multiply that by 100 contacts and the metadata is far larger then the actual data.

I do like the fact that a guid is generated on the client and so you don't have to requery after an initial save. But in my mine, the advantages of the integer key outweigh the advantages of the Guid.

Buy I am wondering if I am missing something as I see so many examples which stick to the Guid despite the larger size.

Greg



Replies:
Posted By: mgood
Date Posted: 10-Jan-2013 at 4:28pm
Database generated Ids violate a fundamental principal of an entity, which says the identity of an entity should never change over its lifecycle. With store generated Ids, the entity gets a temporary id on the client until it is saved and it's identity changes at that point. You will find that to be a headache when building more complex applications. You can't uniquely identify an entity across contexts while it has a temporary id unless you define some sort of an additional business key.
 
In larger systems, Guids also allow for uniquely identityfing things across multiple data stores. That's a very common challenge in larger enterprise systems with multiple datasources.
 

Posted By: gregweb
Date Posted: 10-Jan-2013 at 4:40pm
OK, good points. Once thing I have seen to mitigate the second point is a field called RowGuid which is just a guid, but it doesn't get sent over the wire. I am already too deep in the project to change at this point, but at least I know the choices better.

Greg

Posted By: smi-mark
Date Posted: 11-Jan-2013 at 8:56am
Greg,

I've built a key service in my project that my factories use when creating an entity. It will call a method on the server and allocate an integer key, rather than using identity columns it will use a key table. SQL Server 2012 also offers sequences which would do something similar.  If I think I am going to be creating many entities in succession I can request a range of keys to use.

Something like that might help you if you don't want to use GUIDs.

Posted By: gregweb
Date Posted: 11-Jan-2013 at 9:55am
Yes, but have you actually had any issues with using an Identity column? I have used them in the past with db's that didn't have an identity column, but it seems the present incarnation of DevForce handles the id fixups just fine. I have never had any issues with it so am reluctant to change :)

Posted By: smi-mark
Date Posted: 11-Jan-2013 at 1:02pm
Yes, I have had issues with entity sandboxing and merging entities back that have been saved and such. The keyservice eliminated these issues.

Posted By: gregweb
Date Posted: 11-Jan-2013 at 1:38pm
OK, thanks very much for your insight!

Greg


Print Page | Close Window