What data type do you use for storing IDs?

Question

Why is there a minimum character count for posting questions? o.O

Do you use int, bigint, tinyint, whatever?

It seems like a small thing I guess, I was just wondering what the usual practice is

Answer 1

It all depends ... my favorite answer to a question! =)

Most of the time we use Guids. While they are larger, size-wise, than int, tinyint and so on, I like the fact that my business objects can know what the value is before inserting records into the database.

At other times I may use strings, for things like customer id, where it might need to be easily recognized when working with the database.

Answer 2

I've found int to be plenty large.

Going smaller is pointless . . .

Answer 3

We use GUIDs as well.

It works better to synchronize multiple foreign database into one data warehouse. The drawback is it isn't as easy to figure out which items were created first, but you can still store the creation date or an autonomber if that is truly a problem.

Answer 4

I like Guid's very much. The best thing is they can easily be generated on client or server without making any trips to the database. Also if you have to synchronise databases ever they will be a god send. The only disadvantage I find is with web apps if you pass the key on the url then you can easily get messy query strings.

Answer 5

Wouldn't it depend on how many ids you're likely to need to store over the lifetime of the app?

Answer 6

Need more information. What kind of IDs are you storing? Anything smaller than int is probably a bad idea, a string might make sense given that it doesn't have the tiny issue of running out of digits, and isn't constrained constrained by numbers, so you could use a username as an id, for example.

Answer 7

I'll echo Jason with regards to always having a comparative column when using guids. I prefer sequences over guids though as you'll want a sequence either way.

Datatype-wise, it depends on how many records you need to store, but int usually suffices.