Comments on: Are GUIDs Really the Way to Go? http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go (permanently in beta) Mon, 09 Jan 2012 20:21:24 -0800 http://wordpress.org/?v=2.9.2 hourly 1 By: Strider http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-5118 Strider Wed, 28 Jul 2010 12:22:22 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-5118 You are missing a HUUUUUGE pro of using GUID's. When having to persist entities to a DB that reference each other, you can generate the PK in code without having to go to the DB first to try and find your next available sequence. e.g. PK = GUID.NewGuid() insertPerson(PK,'john') insertChild(GUID.NewGuid(),'peter',PK) => peter is now a child of john with an integer sequence, you would have had to do a query first to determine the next sequence to use as PK, instead of using GUID.NewGuid(). You are missing a HUUUUUGE pro of using GUID’s. When having to persist entities to a DB that reference each other, you can generate the PK in code without having to go to the DB first to try and find your next available sequence.

e.g. PK = GUID.NewGuid()
insertPerson(PK,’john’)
insertChild(GUID.NewGuid(),’peter’,PK) => peter is now a child of john

with an integer sequence, you would have had to do a query first to determine the next sequence to use as PK, instead of using GUID.NewGuid().

]]> By: Larry Groove http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-4923 Larry Groove Tue, 12 Jan 2010 05:57:57 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-4923 After supporting several C# apps that were heavily GUIDed on the database side I am with you. There are clearly situations where a GUID is a very useful feature. Useful enough to make it worth using such cryptic IDs. As much as possible I still find a way to tie a GUID to an integer ID they are just easier to work with remember and COMMUNICATE. I cannot emphasize enough the value of these attributes in troubleshooting situations. In the end I agree that After supporting several C# apps that were heavily GUIDed on the database side I am with you. There are clearly situations where a GUID is a very useful feature. Useful enough to make it worth using such cryptic IDs.

As much as possible I still find a way to tie a GUID to an integer ID they are just easier to work with remember and COMMUNICATE. I cannot emphasize enough the value of these attributes in troubleshooting situations. In the end I agree that

]]> By: Ritchie Annand http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-4843 Ritchie Annand Mon, 11 May 2009 16:25:42 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-4843 The major appeal of GUIDs to me ended up being their ease of use in a distributed system - e.g. a whole mess of remote-area laptops and a couple of satellite offices, apart from the main office. You no longer have to check out key ranges from a central repository or, worse yet, deal with the after-effects of someone installing, getting a key range, and then *ghosting the machine*. That's not fun. There are other schemes for merging data in non-ranged, non-GUID systems, but they're not pretty. The major appeal of GUIDs to me ended up being their ease of use in a distributed system – e.g. a whole mess of remote-area laptops and a couple of satellite offices, apart from the main office.

You no longer have to check out key ranges from a central repository or, worse yet, deal with the after-effects of someone installing, getting a key range, and then *ghosting the machine*. That’s not fun.

There are other schemes for merging data in non-ranged, non-GUID systems, but they’re not pretty.

]]> By: Craig http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-3675 Craig Wed, 28 May 2008 14:54:28 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-3675 If you're interested, we did a podcast about UUIDs in the database: http://www.basementcoders.com/2008/5/12/episode-2-uuids Enjoy! If you’re interested, we did a podcast about UUIDs in the database:

http://www.basementcoders.com/2008/5/12/episode-2-uuids

Enjoy!

]]> By: Brian H. http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-3667 Brian H. Mon, 26 May 2008 19:56:41 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-3667 It is not at all unusual to use chars as primary keys in some situations (for example, a well-defined code universe, such as states, country codes, sex codes, race codes, etc.). In fact, this is the correct modeling technique (natural keys) in many situations. It would be retarded to create a reference table where 17 stands for New York state instead of "NY". (No, this is not the same situation as using a natural key in a master table, such as using an SSN for an Employees table. Different table types call for different considerations.) Your statement that DBMS architects "really had integers in mind for primary keys", that anything other than integers is "flirting with a less-well-tested-use-case" is wrong, very wrong, on both the technical and the relational-theory level, and reveals you as a someone who has not done much reading. You would strengthen your post by removing this claim. Also, for SQL Server at least, GUIDS have their own 128-bit type called "uniqueidentifier". The Microsoft middleware layers (OLE-DB, ADO.NET, the CLR) also have this type. So on that platform at least, your varchar argument doesn't hold water. The argument against GUIDS on that platform is that 128 bits is more than 32 bits, and GUIDS do not cluster as nicely as an auto-incrementing integer. It is not at all unusual to use chars as primary keys in some situations (for example, a well-defined code universe, such as states, country codes, sex codes, race codes, etc.). In fact, this is the correct modeling technique (natural keys) in many situations. It would be retarded to create a reference table where 17 stands for New York state instead of “NY”. (No, this is not the same situation as using a natural key in a master table, such as using an SSN for an Employees table. Different table types call for different considerations.) Your statement that DBMS architects “really had integers in mind for primary keys”, that anything other than integers is “flirting with a less-well-tested-use-case” is wrong, very wrong, on both the technical and the relational-theory level, and reveals you as a someone who has not done much reading. You would strengthen your post by removing this claim.

Also, for SQL Server at least, GUIDS have their own 128-bit type called “uniqueidentifier”. The Microsoft middleware layers (OLE-DB, ADO.NET, the CLR) also have this type. So on that platform at least, your varchar argument doesn’t hold water. The argument against GUIDS on that platform is that 128 bits is more than 32 bits, and GUIDS do not cluster as nicely as an auto-incrementing integer.

]]> By: Jose Noheda http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-2512 Jose Noheda Fri, 16 Nov 2007 08:22:45 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-2512 @Peter: Yes, thank you. We took another approach with custom user types. We noticed it when loaded a couple million rows in a table :-) @Peter: Yes, thank you. We took another approach with custom user types. We noticed it when loaded a couple million rows in a table :-)

]]> By: Peter Mularien http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-2511 Peter Mularien Fri, 16 Nov 2007 01:06:19 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-2511 @Jose - one thing to be careful of with Oracle and RAW datatypes with GUIDs is implicit conversion of Strings to RAW and vice-versa. We ran into performance problems with the exact same setup as you until we created function-based indexes with RAWTOHEX on the RAW columns. Just something to be aware of :) @Jose – one thing to be careful of with Oracle and RAW datatypes with GUIDs is implicit conversion of Strings to RAW and vice-versa. We ran into performance problems with the exact same setup as you until we created function-based indexes with RAWTOHEX on the RAW columns. Just something to be aware of :)

]]> By: Daniel Spiewak http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-2505 Daniel Spiewak Thu, 08 Nov 2007 18:49:58 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-2505 @Jay Just for the record, in your situation I would be very much *in favor* of using GUIDs. :-) When you've got a setup that's permuted across multiple disparate servers like that, I think it'd probably be most flexible to go with something more "guaranteed unique" than an auto-incremented BIGINT. @Jay
Just for the record, in your situation I would be very much *in favor* of using GUIDs. :-) When you’ve got a setup that’s permuted across multiple disparate servers like that, I think it’d probably be most flexible to go with something more “guaranteed unique” than an auto-incremented BIGINT.

]]> By: Jay Levitt http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-2504 Jay Levitt Thu, 08 Nov 2007 18:44:18 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-2504 @rektide: Just saw your post above. Permuting the GUID doesn't help, though; if the application's permuting it, then the application still has to know which DB it wrote to before finalizing the GUID. And if the database is permuting it, then the application still has to wait for the database response to find out the GUID. Either way, you don't get the "I can make [fewer] round trips to the database" benefit that the Gospels promise us. @Daniel: Yep, you understand exactly. Maybe that's not generally needed anymore; at the time, database-layer clustering solutions were immature and not very performant. Still, I have to figure that at some level - either in the application, or hidden in the clustering layer - that's what's happening. I mean, somehow, when I SELECT by primary key, some layer has to be able to find that record from among multiple servers. I think you're right - that the database has to generate the GUID, just as we did it. Which removes the big GUID "win" of "Hey, now I don't have to wait for the database to respond with its auto-generated ID!". So I'm curious to hear how the pro-GUID camp handles that... rektide, Ryan? @rektide: Just saw your post above. Permuting the GUID doesn’t help, though; if the application’s permuting it, then the application still has to know which DB it wrote to before finalizing the GUID. And if the database is permuting it, then the application still has to wait for the database response to find out the GUID. Either way, you don’t get the “I can make [fewer] round trips to the database” benefit that the Gospels promise us.

@Daniel: Yep, you understand exactly. Maybe that’s not generally needed anymore; at the time, database-layer clustering solutions were immature and not very performant. Still, I have to figure that at some level – either in the application, or hidden in the clustering layer – that’s what’s happening. I mean, somehow, when I SELECT by primary key, some layer has to be able to find that record from among multiple servers.

I think you’re right – that the database has to generate the GUID, just as we did it. Which removes the big GUID “win” of “Hey, now I don’t have to wait for the database to respond with its auto-generated ID!”.

So I’m curious to hear how the pro-GUID camp handles that… rektide, Ryan?

]]> By: Daniel Spiewak http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go/comment-page-1#comment-2502 Daniel Spiewak Thu, 08 Nov 2007 18:19:34 +0000 http://www.codecommit.com/blog/database/are-guids-really-the-way-to-go#comment-2502 Whew! Complicated setup. :-) If I understand you correctly, you're letting the database generate the int and then ORing it with a shifted database id (in this case, maybe 57 << 12, depending on how many keys you want to accommodate). This way you can just mask off the top few bits of the id and know which database you're looking at. In such a situation, I think the only way you could keep your round-robin working is to have the database generate a GUID based on an algorithm which would ensure some mathematical property of the GUID was reversable to the database index. For example, taking the GUID MOD num_databases could return the database index, or something like that. This could be done using some sort of stored procedure. When you try the INSERT, you would then pass that stored procedure a parameter giving the database number, which it would use as a seed then in the GUID generation. Does that make any sense? Basically, the trick is the same (being able to find the database number from the primary key value), and you absolutely *must* have the key generated on the database server, be it auto incremented or GUID. Whew! Complicated setup. :-)

If I understand you correctly, you’re letting the database generate the int and then ORing it with a shifted database id (in this case, maybe 57 << 12, depending on how many keys you want to accommodate). This way you can just mask off the top few bits of the id and know which database you’re looking at.

In such a situation, I think the only way you could keep your round-robin working is to have the database generate a GUID based on an algorithm which would ensure some mathematical property of the GUID was reversable to the database index. For example, taking the GUID MOD num_databases could return the database index, or something like that. This could be done using some sort of stored procedure. When you try the INSERT, you would then pass that stored procedure a parameter giving the database number, which it would use as a seed then in the GUID generation.

Does that make any sense? Basically, the trick is the same (being able to find the database number from the primary key value), and you absolutely *must* have the key generated on the database server, be it auto incremented or GUID.

]]>