The 2 biggest pitfalls when assigning IDs

IDs, or identifiers, are everywhere. In systems engineering, we work with IDs that uniquely identify requirements. In PLM, we have part numbers. But we also deal with IDs outside our area of expertise: Websites have URLs, or now URIs (the I stands for "identifier"). Books have an ISDN. And places have addresses.

Identifiers are everywhere and they are important. That's why we should think a little before we commit to a scheme for assigning IDs. Here are the 2 biggest pitfalls.

There are many things to consider when assigning identifiers. However, there are two aspects that frequently lead to problems: The scope for validity and the possible meaning of the ID.

Case 1: Scope was not taken into account

The scope describes the area of validity of an ID. Outside the scope, the ID could be ambiguous.

A classic example from everyday life is the ISBN number on books. The number uniquely identifies the book. But in the end it is simply a 10- or 13-digit number. In another context, the number could be meaningless, have a different meaning or be ambiguous.

Worse still, the moment we start working with databases, we have to be even more careful. Databases generate IDs for their entries, no matter what type of database it is. The temptation here is to also use these for identification outside the database. Although this usually works well, it still has disadvantages: It makes migrations and automatic testing more difficult. We may commit ourselves to a specific database without knowing it. And it can make the migration of data more difficult.

Always generate the ID at application level, do not use database-generated IDs

Three Issues With Using Database Generated IDs

It can also become problematic if the same system (or the same database) is to be used and integrated several times. In this case, we are dealing with non-unique identifiers.

Solution: Analyze scope, generate IDs from the application

It therefore makes sense to get a few Thoughts about the scope and generate suitable IDs at application level based on this. Basically, it makes sense to think about all the required properties of the IDs. More on this in a moment.

Sometimes we cannot assess the scope from the outset. In this case, a globally unique identifier may be useful. We also have several options here.

Globally unique IDs

Here, too, we have many options. Depending on the application, the following two are the most important:

We can use universally unique IDs, so-called UUIDs. These are guaranteed not to exist a second time anywhere in the world. Example:

550e8400-e29b-11d4-a716-446655440000

UUIDs also have disadvantages. For example, they do not contain any sequence information and are not particularly suitable for humans. If these properties are important, but we still cannot assess the scope, we should work with namespaces. The best known approach to this is the URI (Uniform Resource Identifier). These look like a web address. And in fact, many web addresses are also URIs.

A URI has the advantage that it can be shortened if the scope is known. Here is an example:

  foo://example.com:8042/over/there?name=ferret#nose
  \_/ \________________/\_________/ \_________/ \__/
   | | | | |
scheme authority path query fragment
   | _____________________|__
  / \ / \
  urn:example:animal:ferret:nose

For example, if we know that we are on the server example.com:8042, then everything from the path onwards is sufficient to uniquely identify the resource.

At this point we ask ourselves: Do the parts of the identifier have a specific meaning? And that brings us to trap 2:

Trap 2: The ID has semantics

As humans, we are happy when we see an ID and immediately know what it is about. The classic example of this is the vehicle license plate. The letter in the blue field identifies the country, the first letters the city.

In the case of vehicle license plates, we are dealing with a standardized identifier whose meaning will change little over the years, so this may be fine. However, especially in a rapidly changing environment, we quickly create more problems with semantic IDs than we solve, as we are severely limiting ourselves. It gets even worse if the meaning of the identified element can change, for example due to changes in technology. The following article describes this in detail using "talking part numbers":

We must be careful here not to confuse structure and semantics: For example, the URIs shown above have a clear structure. Each structural element has a role (scheme, authority, path). In practice, we can rarely avoid showing certain structures. However, these structures should not have any predetermined meaning beyond the structure.

Conclusion

With software-heavy and increasingly networked systems, the importance of identifiers is growing. IDs are not rocket science and many frameworks help us to generate IDs easily and securely. Nevertheless, we should definitely think about the scope of the IDs before implementation and keep meaning out of the structure of the identifiers. This can save us a lot of trouble in the long term.

Image source: Pixabay