Reasons not to use an auto-incrementing number for a primary key

Question

I\'m currently working on someone else\'s database where the primary keys are generated via a lookup table which contains a list of table names and the last primary key used

Answer 1

My main issue with auto-incrementing keys is that they lack any meaning.

For tables where certain fields provide uniqueness (whether alone or in combination with another), I'd opt for using that instead.

Answer 2

The only real reason to do this is to be database agnostic (if different db versions use different auto-numbering techniques).

The other issue mentioned here is the ability to create records in multiple places (like in the central office as well as on traveling users' laptops). In that case, though, you would probably need something like a "sitecode" that was unique to each install that was prefixed to each ID.

Answer 3

from CodingHorror:

GUID Pros

• Unique across every table, every database, every server
• Allows easy merging of records from different databases
• Allows easy distribution of databases across multiple servers
• You can generate IDs anywhere, instead of having to roundtrip to the database
• Most replication scenarios require GUID columns anyway

GUID Cons

• It is a whopping 4 times larger than the traditional 4-byte index value; this can have serious performance and storage implications if you're not careful
• Cumbersome to debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• The generated GUIDs should be partially sequential for best performance (eg, newsequentialid() on SQL 2005) and to enable use of clustered indexes

The article provides a lot of good external links on making the decision on GUID vs. Auto Increment. If I can, I go with GUID.

Answer 4

Using a unique identifiers would allow you to merge data from two different databases.

Maybe you have an application that collects data in multiple database and then "syncs" with a master database at various times in the day. You wouldn't have to worry about primary key collisions in this scenario.

Or, possibly, you might want to know what a record's ID will be before you actually create it.

Answer 5

An auto generated ID can cause problems in situations where you are using replication (as I'm sure the techniques you've found can!). In these cases, I generally opt for a GUID.

If you are not likely to use replication, then an auto-incrementing PK will most likely work just fine.

Answer 6

The procedure method of incrementing must be thread safe. If not, you may not get unique numbers. Also, it must be fast, otherwise it will be an application bottleneck. The built in functions have already taken these two factors into account.