6

If an Entity doesn't have an unique ID, we usually use auto increment number to distinguish entities. But sometimes, we have to hand that ID over to people so that they can use it. So using auto incremented numbers is not a good fit for this.

Think about IDs you give to students to distinguish them. In that case, IDs should have fixed length. You can't give them 1, 2, 3, etc.

In university, we all had student numbers which were 8 digits (mine was 00260014).

First 2 digits: The year we got accepted to university (00 = 2000).
Next 3 digits: The department (260 = Computer Sciences).
Last 3 digits: The order

Think about SSN. It's is a nine-digit number in the format "AAA-GG-SSSS". First 3 digits were denoting area numbers. Then in June 2011, SSA changed the SSN assignment process to "SSN randomization". That way, one couldn't infer which area an SSN is assigned to. It gives some anonymity and security.

Now I am basically trying to do something similar, trying to assign unique numbers (and maybe some letters too) to all of web services available in my company.

Is is a good idea to put some information about web service in the IDs? Or I should do it completely random?

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
ramazan polat
  • 199
  • 5
  • 1
    See also [this](http://stackoverflow.com/questions/63090/surrogate-vs-natural-business-keys) and [this](http://stackoverflow.com/questions/20052799/surrogate-key-vs-natural-key-for-ef), among about a billion others. – John Wu Mar 11 '17 at 07:08
  • 1
    Oh and [this one](http://softwareengineering.stackexchange.com/questions/340761/embedding-data-inside-ids-good-idea) that I answered recently. Come to think of it maybe I should mark this as a duplicate. – John Wu Mar 11 '17 at 07:10

1 Answers1

3

Encoding meaning into an Entity Id can be useful if the meaning will be used by users.

Handling collisions is one problem that can get rather nasty. You first have to ensure that your system has a low likelihood of producing a collision, and when it happens, you need some mechanism to disambiguate them.

And things get much more interesting when your Id generating code has a subtle bug that goes unnoticed for a while in production. Then you could end up with a bunch of IDs that don't quite fit the pattern and encode subtly wrong, but because they're already in use out there, you either correct them on your side and then implement some sort of correction mapping, or you just leave them as is and hope the users don't notice and hope it doesn't break anything else that relies on the meaning in the ID.

And your example with the SSA and SSNs shows that sometimes meaning in an identifier could cause problems beyond just technical ones.

If your system doesn't really need it (if it won't add any major value), I'd recommend just sticking with an auto-incremented numeric ID.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • 1
    To add to this sometimes you have a unique identifier that you are certain does not change only to discover that it does change. An example could be a SSN that contains information of the gender of the person which can change or the SSN can even be changed to hide a person from harmful people (witness protection/protection against family). – Bent Mar 10 '17 at 22:57