In every software application there is a need to uniquely identify objects. Depending on their real-life representation there are properties, which naturally serve as a unique key. For example a car object can use its plate number, a person object can use their fingerprint image, a flight can use its code etc. But other objects doesn’t possess such properties i.e. a shipment object, a purchase object, a customer object. They need something artificial  to be added, so they are uniquely identifiable in the application.

Number as ID

A decade ago when relational databases were at their peak, it was considered a best practice to always have a surrogate primary key implemented as auto-generated sequential numbers. That gives every object a unique number in its own context and makes it uniquely identified regardless of its natural properties. A big advantage of that is relations between objects of different types can be done easily but the disadvantage is that identifiers overlap between object types.

Example:

Clients         Orders
Id, Name        Id, ClientId, Amount
 1, Peter        1,        2,    100
 2, John         2,        2,     40
 3, Mark         3,        1,     85

Identifiers of Clients and Orders are the same but within their type they are unique.

Universal Unique Identifiers

With the boom of APIs, Web and Mobile applications it became necessary to uniquely identify objects across systems without depending on their type. To that necessity added the rapid development of Non-relational (document, key-value etc.) databases that store and index a huge number of objects of different types in a single index. As a result Universal Unique IDentifiers (UIID) were invented (See rfc4122 and Wikipedia UUID)

Example
Version 4 UUID: 40afcb6b-6213-4924-835a-33e175f2f150

UUIDs give a higher level of uniqueness although there is a slight chance of collision (non-unique id). Today they are widely adopted as they are very good for sharing objects across the Internet and providing external system users an easy way to refer to objects.

In the world of relational databases these can be used to relate objects but they use more space, create larger indices and when relations are followed by a human it is not that convenient.

Numbers or UUIDs ?

So why not take the best of those two worlds and use both of concepts at the same time?

Here’s my little set recipe:

• Every object must have an auto-generated sequence number (ID)
• Every object must have a UUID
• IDs are used ONLY inside the application that has created them
• UUIDs are used when that object must be shared outside of the application

What do you use?

Share your thoughts, experience, recipes, guidelines and recommendations!