Hi,

This is a newbie question I guess.

I am not clear on when one should use a DB-generated id column versus a composite key. I mean, I can think up of specific instances where a table's primary key naturely *feels* like it should consist of multiple components. For example:

Table ImageDimension
- width
- height
- reference count

In the above case, I would assume one should use a composite key consisting of width and height because it feels natural that a dimension is uniquely defined by its width and height. We don't want to end up with two separate instances having the same width and height.

Does one only use the "id" approach when there is no clear concept of what the primary key should be? Please give me some tips on "best practices".

Thank you,
Gili

As a follow-up question, are there performance issues with picking one approach over the other? Should I not concern myself with that and instead focus on what makes sense from a design point of view?

Gili

Don't use primary keys with a business meaning. If the business chanages you will be in trouble.

Use one of the technical key mechanisms your DBMS provides.

HTH
Ernst

Is there *ever* a valid reason for using composite keys?

Gili

In the hibernate in action book they strongly suggest using arbitrary sequences for primary key fields and to put unique indexes on surrogate keys(unique keys with business meaning).

Hope this helps.

Thanks Javamac!

I looked up the term surrogate keys and found this http://www.bcarter.com/intsurr1.htm which and http://www.dbmsmag.com/9805d05.html

It makes a more sense now.

Thank you,
Gili

If you have a legacy DB sometines you don't have an option.

HTH
Ernst