Should I design a table with a primary key of varchar or int?

Question

I know this is subjective, but I\'d like to know peoples opinions and hopefully some best practices that I can apply when designing sql server table structures.

I pe

Answer 1

Keeping in mind that this is quite old a question, I still want to make the case for using varchar with surrogate keys fur future readers:

1. An environment with several replicated machines
2. Scenarios where it is required that the ID of a to be inserted row is known before it is actually inserted (i.e., the client assigns this ID, not the database)

Answer 2

For best performance, 99.999% of the time the primary key should be a single integer field.

Unless you require the primary key to be unique across multiple tables in a database or across multiple databases. I am assuming that you are asking about MS SQL-Server because that is how your question was tagged. In which case, consider using the GUID field instead. Though better than a varchar, the GUID field performance is not as good as an integer.

Answer 3

One should think hard about whether 32-bit range is enough for what you're doing. Twitter's status IDs were 32-bit INTs and they had trouble when they ran out.

Whether to use a BIGINT or a UUID/GUID in that situation is debatable and I'm not a hardcore database guy, but UUIDs can be stored in a fixed-length VARCHAR without worrying that you'll need to change the field size.

Answer 4

We have to keep in mind that the primary key of a table should not have "business logic" and it should be only an identity of the record it belongs. Following this simple rule an int and especially an identity int is a very good solution. By asking about varchar I guess that you mean using for example the "Full Name" as a key to the "people" table. But what if we want to change the name from "George Something" to "George A. Something" ? And what size will the field be ? If we change the size we have to change the size on all foreign tables too. So we should avoid logic on keys. Sometimes we can use the social ID (integer value) as key but I avoid that too. Now if a project has the prospects to scale up you should consider using Guids too (uniqueidentifier SQL type).

Answer 5

I'd agree that in general an INT (or identity) field type is the best choice in most "normal" database designs:

• it requires no "algorithm" to generate the id/key/value
• you have fast(er) joins and the optimizer can work a lot harder over ranges and such under the hood
• you're following a defacto standard

That said, you also need to know your data. If you're going to blow through a signed 32-bit int, you need to think about unsigned. If you're going to blow through that, maybe 64-bit ints are what you want. Or maybe you need a UUID/hash to make syncing between database instances/shards easier.

Unfortunately, it depends and YMMV but I'd definitely use an int/identity unless you have a good reason not to.

Answer 6

Use INT. Your points are all valid; I would prioritize as:

1. Ease of using SQL auto increment capabiity - why reinvent the wheel?
2. Managability - you don't want to have to change the key field.
3. Performance
4. Disk Space

1 & 2 require the developer's time/energy/effort. 3 & 4 you can throw hardware at.