25
wcypierre
17d

boss: doesn't want guid as public facing id
me: *okaymeme* proceeds to study id generation methods....

*fast forward 2 weeks*

me now: for every site that I go to, I will take a look and study how is their id generated...........

#idobsession (╯°□°)╯︵ ┻━┻

Comments
  • 7
    Sounds like a good id :p

    Welcome to DevRant! May you transcend Green-Dotness soon
  • 3
    @alexbrooklyn thanks! it is still beyond me that how big the number is for just 6 letters (or even 5 letters) in base36 (which is used in reddit)
  • 2
    You can use another guid as a naturalId.

    Although it all depends on you boss'es reasoning
  • 1
    Excellent first post!

    Even amazon only uses base34 numbers in a 4 char sequence on boxes for packages. Internally it's still UUID bc fast.

    Hopefully your boss had a good reason for all the extra engineering effort >.<
  • 0
    @netikras the boss wanted no running number (guessable) and guid is too complex for him and so yeah
  • 0
    @SortOfTested likely they are using base34 because of the O and I colliding with 0 and 1 issue. But then, 4 letters in base34 only sums up to 1.3 million, feels like there is more to it as Amazon definitely handles more than that in a day....

    The reasoning for the extra dev work is mentioned above and so yeah (well at least I get to spend some good time on maths while still doing work)
  • 0
    @wcypierre
    That is why we used the scheme, yes. It allows customer support agents to get to an order faster and delivery people to look up information in their queue faster to see order details. The same values are reused at every endpoint distribution center every day.
  • 0
    @SortOfTested got it. earlier while thinking of the structure, we've also discussed about whether to have a single unique id (easier for customer support), or to have repeatable id (per day or until it finishes and repeat again, but then customer support would need to ask more info and so we scrapped that idea)
  • 0
    @wcypierre still doesn't answer WHY. Security concerns? Easy -- just use unique IDs in user-scope, i.e. each user can have IDs in a range [0, Long.MAX_VALUE]. This way my first order will be #1, second -- #2, etc. Your first order will be #1, second - #2, etc. And we can refer to order #1 and we'll only be navigating in our user's scope - no way to access any other user's orders.
    ofc the backend has to do the user_id+order_id=>PK(GUID) mapping, but that's a negligible overhead.

    If entities are to be shared among users [i.e. not possible to scope per-user], you can use slugs of their textual representation. Although I guess that might be somewhat guessable, but then any ID is. The slug value is clear when read - you can also append some random number to the end to increase probability of uniqueness (you can encure random+slug uniqueness upon persistance).

    But since IDK your use-case it's difficult to drop anything fitting your bill well enough :)

    but "uuid is too complex" is weird...
Add Comment