SQL Server GUID (from Active Directory) vs Int

Question

We migrated a lot of data from our old ordering system. This system stored the users initials in our "Orders" table for each order they created. Now that we have a view that looks at active directory I would like to update those initials with the active directory objectguid (or something that references the guid). This would allow us to change the users initials in active directory without having to worry about updating the "Orders" table records.

I've read that index performance is lackluster when using guids vs ints. One way to possibly solve this is have a table that maps guids to ints then store the int value in our orders table. Would this be a good idea? Any thoughts?

Answer 1

I assume that a USER entity already exists in your database design however, if it does not then I believe your solution will require it.

So assuming the USER entity exists, as you have described, you could place the UserID(int) on the ORDERS table, thereby relating all relevant USER details to an ORDER, rather than just initials (Note: Initials should arguably not be stored on the ORDER table but rather the USER or USER_DETAILS table, albeit not the focus of this discussion).

You can then add the GUID column to the USER table. I don’t think a separate lookup table is necessary.

Make sense?

Answer 2

Index performance on GUIDs is in general no different from other indexes on a 16-byte field. Where the GUID's are deadly for performance is when you use them as clustering key on a SQL Server table.

The SQL Server table is the clustered key and is physically ordered by that key. Since the GUIDs are by nature totally random, this leads to massive index fragmentation very quickly, and thus requires a) constant feed and care and reorganization, but b) still suffers even if you reorganize every night. So really, the best practice would be to avoid GUIDs (even the new "sequential" GUIDs) for your clustering key.

For more background info and some excellent write-ups on why GUIDs make very poor clustered keys, see the blog of the "Queen of Indexing", Kimberly Tripp:

• GUIDs as primary key
• The clustered index debate continues....
• The clustered index debate....again!

Her insight is most valuable - read it, internalize it, follow it! You won't regret it.

Marc