Strategy for coping with database identity/autonumber maxing out

Question

Autonumber fields (e.g. "identity" in SQL Server) are a common method for providing a unique key for a database table. However, given that they are quite common, at some point in the future we'll be dealing with the problem where they will start reaching their maximum value.

Does anyone know of or have a recommended strategy to avoid this scenario? I expect that many answers will suggest switching to guids, but given that this will take large amount of development (especially where many systems are integrated and share the value) is there another way? Are we heading in a direction where newer hardware/operating systems/databases will simply allow larger and larger values for integers?

Answer 1

If you really expect your IDs to run out, use bigint. For most practical purposes, it won't ever run out, and if it does, you should probably use a uniqueidentifier.

If you have 3 billion (that means a transaction/cycle on a 3.0GHz processor) transactions per second, it'll take about a century for bigint to run out (even if you put off a bit for the sign).

That said, once, "640K ought to be enough for anybody." :)

Answer 2

See these related questions:

• Reset primary key (int as identity)
• Is bigint large enough for an event log table?

The accepted/top voted answers pretty much cover it.

Answer 3

Is there a possibility to cycle through the numbers that have been deleted from the database? Or are most of the records still alive? Just a thought.

My other idea was Mehrdad's suggestion of switching to bigint

Answer 4

Identity columns are typically set to start at 1 and increment by +1. Negative values are just as valid as positive, thus doubling the pool of available identifiers.

Answer 5

If you may be getting such large data amounts that your IDs max out, you may also want to have support for replication so that you can have multiple somehow synchronized instances of your database.

For such cases, and for cases where you want to avoid having "guessable" IDs (web applications etc.), I'd suggest using Guids (Uniqueidentifiers) with a default of a new Guid as replacement for identity columns.

Because Guids are unique, they allow data to be synchronized properly, even if records were added concurrently to the system.