views:

248

answers:

7

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

Anyway, my question is as clear as can be from the title. Do you use int, bigint, tinyint, whatever.

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

+1  A: 

I've found int to be plenty large.

Going smaller is pointless . . .

TrickyNixon
+6  A: 

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.

mattruma
From a SQL Server perspective GUIDs are fine as AKs but suck as PKs through the fill-factor busting index page fragmentation that they cause. Instead we *always* uses Ints of some variety for PKs.
stephbu
Well said stephbu. I've used GUIDs in the past when I know that table length will be small and transaction volume low but went back to ints for simple convenience sake.
TrickyNixon
In most of our development we have plenty of disk space, plenty of network bandwidth and plenty of server power ... which is why we lean towards the Guids If I had to write a consumer product I would probably lean towards integers or strings.
mattruma
A: 

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

Paul Tomblin
A: 

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.

tloach
+1  A: 

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.

Jason Kealey
+1  A: 

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.

Craig
A: 

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.