in general, should every table in a database have an identity field to use as a PK?

Question

This seems like a duplicate even as I ask it, but I searched and didn\'t find it. It seems like a good question for SO -- even though I\'m sure I can find it on many blogs e

Answer 1

If you have modelled, designed, normalised etc, then you will have no identity columns.

You will have identified natural and candidate keys for your tables.

You may decide on a surrogate key because of the physical architecture (eg narrow, numeric, strictly monotonically increasing), say, because using a nvarchar(100) column is not a good idea (still need unique constraint).

Or because of ideology: they appeal to OO developers I've found.

Ok, assume ID columns. As your db gets more complex, say several layers, how can you jon parent and grand-.child tables directly. You can't: you always need intermediate tables and well indexed PK-FL columns. With a composite key, it's all there for you...

Don't get me wrong: I use them. But I know why I use them...

Edit:

I'd be interested to collate "always ID"+"no stored procs" matches on one hand, with "use stored procs"+"IDs when they benefit" on the other...