GUIDs Are Not the Only Answer

Re:GUIDs Are Not the Only Answer by dehrmann on Wednesday January 06, 2021 @03:13AM (#25655650)

Strings have their own issues. One place I worked had a bug where users could take over accounts because of missing/inconsistent unicode canonicalization. Case can be a problem, as can special characters.

There's something to be said for strings, though. Prefixed IDs that mark the type can be nice to work with when it's an otherwise opaque ID, but they're a pain to handle internally.

If you're storing third-party IDs, you probably want strings...unless their clever JSON API returns 1.3E6 as a number. Or the string "null;" that's always an adventure.

[ Parent | on HN ]

Re:GUIDs Are Not the Only Answer by fiddlerwoaroof on Wednesday January 06, 2021 @11:13PM (#25667206)

IDs should really be their own type: string operations don’t really make sense on them. If you use strings, there should probably be a constraint on the acceptable characters and lengths: e.g. only digits, exactly 10 or something like that.

I personally like the idea of using urls using a domain you control + a path that reflects the type of data it’s an ID for.

[ Parent | on HN ]

Re:GUIDs Are Not the Only Answer by naniwaduni on Wednesday January 06, 2021 @11:14PM (#25667215)

To be fair, string operations don't usually make much sense in general.

[ Parent | on HN ]

Re:GUIDs Are Not the Only Answer by katbyte on Thursday January 07, 2021 @03:55AM (#25668823)

azure does this for resource IDs and its one of the few things i really enjoy about the platform.

[ Parent | on HN ]

Re:GUIDs Are Not the Only Answer by ivanb on Thursday January 07, 2021 @02:28AM (#25668235)

If the main benefit of prefixed IDs is debugging then a dev tool can be created that would just look up the ID in all tables and report what object it corresponds to.

[ Parent | on HN ]