0

One of our clients requires us to store GUIDs as string values. To do this we store the value as a char(32) and strip off the braces and hyphens. All over the interwebs, however, you see people storing it as char(36). Why? Is there a benefit to NOT stripping the GUID of its cosmetic characters? I'd think you'd want to save the space whenever possible.

Christian Phillips
  • 18,399
  • 8
  • 53
  • 82
Ryan D'Baisse
  • 837
  • 11
  • 29
  • Well, that stripping presumably takes a small amount of time (and effort to get right, of course). Perhaps storage is cheap but compute time expensive in those situations? – Jon Skeet Jul 15 '14 at 12:41
  • 3
    But if you really care about space, you'd store as (in SQL Server, `uniqueidentifier`) the database's GUID data type or if it doesn't have one, `binary`. – Damien_The_Unbeliever Jul 15 '14 at 12:42
  • Probably depends what you're doing with it. If you're storing it as string because, say, you want to quickly match against a GUID that's passed to you as a full string—from a bit of XML, say—then it's going to be faster to do an indexed lookup on a string that's in exactly the same format. Or maybe they're serving it up to clients in the full standard format, and this way they won't need to fiddle with it on the way out of the database... Are you seeing this in SQL Server "all over the interwebs", or just for databases that don't have a native GUID type? – Matt Gibson Jul 15 '14 at 12:46
  • might be worth looking at http://stackoverflow.com/questions/412341/how-should-i-store-guid-in-mysql-tables as well, even though not an identical question – mc110 Jul 15 '14 at 12:49
  • 1
    It's just a matter of convention. If you see a string with braces and hyphens, you immediately think "hey, that's a GUID!" while a string with only hex characters could be a hash or something else. – Davio Jul 15 '14 at 12:52

0 Answers0