Search code examples
c#.netguiduniqueidentifieridentifier

Generate short, unique identifiers

I'm looking for an algorithm which generates identifiers suitable for both, external use in e.g. URLs as well as persistence with the following requirements:

  • Short, like a max. of 8 characters
  • URL-friendly, so no special characters
  • Human-friendly, e.g. no ambigous characters like L/l, 0/O
  • Incremental for fast indexing
  • Random to prevent guessing without knowing the algorithm (would be nice, but not important)
  • Unique without requiring to check the database

I looked at various solutions, but all I found have some major tradeoffs. For example:

  • GUID: Too long, not incremental
  • GUID base64 encoded: Still too long, not incremental
  • GUID ascii85 encoded: Short, not incremental, too many unsuitable characters
  • GUID encodings like base32, base36: Short, but loss of information
  • Comb GUID: Too long, however incremental
  • All others based on random: Require checking the DB for uniqueness
  • Time-based: Prone to collisions in clustered or multi-threaded environments

Edit: Why has this been marked off-topic? The requirements describe a specific problem to which numerous legitimate solutions can be provided. In fact, some of the solutions here are so good, I'm struggling with choosing the one to mark as answer.

Solution

  • If at all possible I'd keep the user requirements (short, readable) and the database requirements (incremental, fast indexing) separate. User-facing requirements change. You don't want to have to modify your tables because tomorrow you decide to change the length or other specifics of your user-facing ID.

    One approach is to generate your ID using user-friendly characters, like
    23456789ABCDEFGHJKLMNPQRSTUVWXYZ and just make it random.

    But when inserting into the database, don't make that value the primary key for the record it references or even store it in that table. Insert it into its own table with an identity primary key, and then store that int or bigint key with your record.

    That way your primary table can have an incremental primary key. If you need to reference a record by its "friendly" ID then you join to your friendly ID table.

    My guess is that if you're generating a high enough volume of these IDs that you're concerned about index performance then the rate at which human users retrieve those values will be much lower. So the slightly slower lookup of the random value in the friendly ID table won't be a problem.