News for hackers. Stuff that matters.

A comment on Be Careful with UUID or GUID as Primary Keys. Parent comment

Re:Be Careful with UUID or GUID as Primary Keys by sp332 on Friday June 09, 2017 @03:34PM (#14523823)
Oh yeah, that makes sense. At least for CHAR(36), but I'm not sure how VARCHAR(36) as given in the article would behave. (Never mind I just looked it up and it depends on the storage engine - e.g. MEMORY will always allocate the max size.)
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by bitJericho on Friday June 09, 2017 @03:47PM (#14523917)
You'd be insane to put the primary key in a varchar. Mysql is much faster with static width tables. Your main user table should be static width for all the fields.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by cwyers on Friday June 09, 2017 @03:56PM (#14523997)
As opposed to the insanity of storing UUIDs as strings at all? Once you start going into the rabbit hole, you better be prepared to go all the way down.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by bitJericho on Friday June 09, 2017 @04:02PM (#14524046)
No doubt. You can store them as INTs! Tho it does get a little hairy dealing with the conversion with MySQL.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by paulryanrogers on Friday June 09, 2017 @04:23PM (#14524231)
Is this true for all storage engines?
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by morgo on Friday June 09, 2017 @04:52PM (#14524457)
It is not true for innodb (default). See my other comments in this thread.
[ Parent | on HN ]
Re:Be Careful with UUID or GUID as Primary Keys by sroussey on Friday June 09, 2017 @08:16PM (#14525516)
Storage, and index are different. You expand the UTF8 chars into bytes that are then part of a binary tree. It actually gets more interesting when you consider the collations.
[ Parent | on HN ]