Database-wide unique-yet-simple identifiers in SQL Server

Question

First, I\'m aware of this question, and the suggestion (using GUID) doesn\'t apply in my situation.

I want simple UIDs so that my users can easily communicate this i

Answer 1

Why not use identities on all the tables, but any time you present it to the user, simply tack on a single char for the type? e.g. O1234 is an order, D123213 is a delivery, etc.? That way you don't have to engineer some crazy scheme...

Answer 2

I would implement by defining a generic root table. For lack of a better name call it Entity. The Entity table should have at a minimum a single Identity column on it. You could also include other fields that are common accross all your objects or even meta data that tells you this row is an order for example.

Each of your actual Order, Delivery...tables will have a FK reference back to the Entity table. This will give you a single unique ID column

Using the seeds in my opinion is a bad idea, and one that could lead to problems.

Edit

Some of the problems you mentioned already. I also see this being a pain to track and ensure you setup all new entities correctly. Imagine a developer updating the system two years from now.

After I wrote this answer I had thought a but more about why your doing this, and I came to the same conclusion that Matt did.

Answer 3

You could create a master UniqueObject table with your identity and a subtype field. Subtables (Orders, Users, etc.) would have a FK to UniqueObject. INSTEAD OF INSERT triggers should keep the pain to a minimum.

Answer 4

I had a similar situation with a project.

My solution: By default, users only see the first 7 characters of the GUID.

It's sufficiently random that collisions are extremely unlikely (1 in 268 million), and it's efficient for speaking and typing.

Internally, of course, I'm using the entire GUID.

Answer 5

I use a high/low algorithm for this. I can't find a description for this online though. Must blog about it.

In my database, I have an ID table with an counter field. This is the high part. In my application, I have a counter that goes from 0 to 99. This is the low part. The generated key is 100 * high + low.

To get a key, I do the following

initially high = -1
initially low = 0

method GetNewKey()
begin
  if high = -1 then
    high = GetNewHighFromDatabase

  newkey = 100 * high + low.
  Inc low
  If low = 100 then
    low = 0
    high = -1

  return newKey
end

The real code is more complicated with locks etc but that is the general gist.

There are a number of ways of getting the high value from the database including auto inc keys, generators etc. The best way depends on the db you are using.

This algorithm gives simple keys while avoiding most the db hit of looking up a new key every time. In testing, I found it had similar performance to guids and vastly better performance than retrieving an auto inc key every time.