Wade Wright is preaching that IDs in a database should always be GUIDs and lists four reasons. I commented there with my opinions but it hasn’t shown up – some people like to censor if you don’t agree with them completely. My points addressing each of his four ‘reasons’ were:
- Avoid round-trips when creating new business objects I don’t know about you but I don’t populate my IDs until I persist and not on object creation so this reason is irrelevant.
- Data merging is easy Yes, this is a good reason to use GUIDs if you know merging is likely to happen.
- Type/table ignorance Basically he says here that a foreign key reference might relate to a row in any table which breaks relational concepts big time.
- Some weird anecdote I don’t quite get
He does acknowledge that querying the database by hand is a bit of a pain but underestimates the Guid/uniqueidentifier performance penalty in SQL Server especially with regards to INSERTs (might be able to optimize there by having .NET generate the GUID instead of SQL Server).
There are many valid scenarios for using GUIDs as unique identifiers but one size does not fit all using them without consideration will likely lead to somewhere bad ;-)
If you are using them and space is tight such as uncompressed HTML or the GET/POST size down you can write and parse the Guid as Base64 instead of hex format which cuts a Guid of
81187ecf-c452-4550-9ed2-8a51e3c46da1 (36 bytes) to
z34YgVLEUEWe0opR48RtoQ== (22-24 bytes) which soon adds up. To do that in C# and .NET simply:
string base64 = Convert.ToBase64String(guid.ToByteArray()); Guid guid = new Guid(Convert.FromBase64String(base64));