I'm creating a new data model for a new web application constructed using spring and hibernate.

The data model is currently 3nf, I've got my sequencer-generated primary keys, foreign key relationships are all defined properly, etc.

But as I review the hibernate doco I'm starting to wonder if I should be adding some elements to facilitate hibernate...

For example, in order to support the detached pojos I'm thinking I need to include a 'version' column to support the version tag of the definition file...

Basically I need to know if there are things that I should add to my data model (like the version column) that will make hibernate usage better...

The short answer is no. Hibernate can usually map any reasonable schema.

The 'version' column is only useful if you want to use optimistic locking that can be considered as an optional extra feature.

I understand that the version is needed for the optimistic locking, and since I'm using detached pojos the usage of optimistic locking will (according to the online doco) offer the best performance in this situation.

But I'm wondering if, through other additional columns that I'm as yet unaware, there may be other performance and/or optimizations that I should consider now as I'm still in the design phase.

Currently the 'version' column is already on the list, but are there others?

No

Optimistic locking doe's not help for performance, it just lets to detect comflict outside transaction. If you do not need update/delete comflict detection then you do not need this stuff. You can maintain this it yourself for scalability reasons too, "optimistic locking" is easy way, but it needs to keep session state on server per user (scalability is limited by user count).

From the hibernate doco:

"We very strongly recommend that you use version/timestamp columns for optimistic locking with Hibernate. This is the optimal strategy with respect to performance and is the only strategy that correctly handles modifications made to detached instances (ie. when Session.merge() is used)."

So it would not appear to necessarily be tied just to conflict detection per se. As I'm building a web app and will be using detached objects (with at least update capabilities), I'm thinking the version is the way to go.

RE: performance, the doco quote states that it is the best implementation wrt performance (probably in respect to the conflict resolution) which is why I had mentioned performance in my original post.

There is no "the best implementation", I think it is better to store "version" on client ("hidden" field in web form) for comflict detection. JBPM, workflow or state machines are usefull for more advanced state management.