3 ms·

What do you suggest otherwise?

• forgotmypw17 6y ago
  There are many options... alphanumeric case insensitive numeric only keyword based above combined with date or topic just about anything is better than case sensitive mixed alphanumeric plus dashes and underscores, which is a challenge even to techies. Just imagine trying to tell someone a youtube id over voice
  • yakshaving_jgt 6y ago
    And for each of those, how do you avoid risk of collision? A numeric only ID with the same risk of collision as a UUIDV4 would be 39 digits long, which is longer than a UUIDV4. So is there really a benefit? If it's keyword based, how long is the URI allowed to be? Given the need to support [probably well] over a billion records, I don't think your suggestions meet the design constraints.
    • forgotmypw17 6y ago
      a) it's similar for avoiding collisions, and depends more on your hash algo than the display format. b) the benefit, as stated above, is human readability and shareability and typeinability and writedownability
    • Dylan16807 6y ago
      Collisions are a separate issue from encoding. Since we're treating youtube IDs as acceptable, let's assume 64 bits is enough. It's 11 characters with this encoding. With something like Base32, designed so that you can read it out loud and ignore the case, it would take 13 characters. That sounds like a worthy trade-off to me. It's not visually much bigger, and saying it out loud or transcribing it is actually much faster because you don't have to specify case or squint to determine I/l/1 or O/0 etc.