Howdy folks,

Our DBAs are getting a bit shirty about our Hibernate oriented schema design.
The current issue is surrogate keys.

Frankly, surrogate keys these days are an automatic design decision for me because I've been burned too many times when "things change". Even if I was writing the code by hand I'd still be asking for them.

What I need now is the opinions of other people. Because of course, the opinions of the people hired to do the job based on skills and experience is not sufficient.

Does anyone know of any impressive "definitive source" for the pros and cons of surrogate keys?

Cheers,
Shorn.

Oh, also:

Where's a good place in the Hibernate doco that says "we'd really rather you used surrogate keys"?

I can't find anything definitive, but I'm pretty sure Hibernate prefers the use of surrogate keys, yes? I need reasons why.

There is no universal law, only best practice.

Don't use keys that change (business does) and if you can't find candidates, use surrogate keys. If you need composite keys for a unique natural key, consider a surrogate key instead. Beware: some natural keys look unique at first, but are not. This is where your DBA comes in, he should have the experience to find a good key for your data.

Hibernate works with surrogate, natural or composite keys just fine. I always use surrogate keys if I start with a new database. I don't see a reason to look for candidate keys first and I never had problems with surrogate keys. On the other hand, I got burned once with a natural key. Some people might argue that, if you can't find a natural unique key, your entity might miss some attributes. I can't see the point in this argument though.

A good summary: http://www.bcarter.com/intsurr1.htm

Section 5.13 from the manual:
"If you've fully embraced our view that composite keys are a bad thing and that entities should have synthetic identifiers (surrogate keys),"

Natural keys mean to me personally that eventually, you will have composite keys. From my reading of the formus, I've gotten the impression that certain things won't work at their best when Hibernate is asked to use composite-keys.
Am I wrong?
Is there no real argument for using surrogate keys with Hibernate?

Composite keys complicate your schema. This is not only true for ad-hoc SQL queries, DDL generation, etc, but of course also for the Hibernate mapping. As I said before: If you need a composite for a unique natural key, you should consider a surrogate key.

Ok, but other than increased complexity, there's no reason not use composite keys with Hibernate? That is, all features are supproted with composite keys?

Eh, that is a difficult one. :) I'd say that all important features are supported. It's not fun anymore, of course.

Natural keys are just evil.

Hibernate allows you to use them because most legacy database schemas have them somewhere.