Hi,

I am about to start writing my master's project and I have first solid dilema.

I have a choice
1. create as normalized db as it is possible, using multiple primary keys and complitated hibernate composite keys. The advantage - well designed database.
2. create java classes extending base model with hibernate.id and set it as primary key in each table, even many-to-many junction tables (or maybe here i could make an exception). The disadvantage - not good database - i.e. class:
Worker
hibernate.id id
personalID - unique personal data, one in the country for one person,
otherNumber - unique personal data, one in the country for one person,
I NEED TO HAVE TWO fields which normally would be primary keys - if I had only personalID, my problem would be simple resolved - put unique constraint to avoid data repetition. But there will be tables with >=2 id fields apart from hibernate.id (third one). To the bes of my knowledge I can't set composite unique constraints on a table. in POSTGRE SQL 8

then i would have possibility to put into my db the same worker many times, which is an error. Nex disadventage would be that befor insert of such a worker i would hav to check in my code if he hasn't been already inserted.

But i've found in your tutorial http://www.hibernate.org/hib_docs/v3/re ... rial-intro :




So could u please tell me why should I follow it? I am not experienced enough to outnumber the disadvantages that i've mentioned.
Could u point them to me so that i could use these hints in my project ?
I have to justify resigning from normilized db and putting some objectId in each table just for hibernate..

I also want to use HibernateTemplate :
protected BaseModel readModel(Class clazz, Long id) {
return (BaseModel) getHibernateTemplate().load(clazz,id);
}
but I could always make a select query.

is there any experienced hibernatist that could answer :P ?

your db will still be normalized if you use surrogate id's.

But you'll still be better off (IMO) by having a single primary key on each table if your are designing from scratch. If they serve no other purpose that as a row identifier, it will still make your ORM life easier in the long run. For instance (as I believe you mentioned), it allows you to extends your POJOs from a single base class with an identifier, and lemme tell you, there is a lot of common functionality that you would want to incorporate in a base class. This also allows you to write generic DAO methods, using the BaseModel (or whatever) class to perform common operations (persist, delete, etc).

You do not need a base class to implement generic DAOs. You need generics: http://www.hibernate.org/328.html

I certainly already use that methodology for DAOs, and highly suggest it! But I also derive all of my model classes from BaseModel, which allows me to use <T extends BaseModel> in the generics of the DAOs, which then allows me to implement more common functionality (e.g. all my model also have 4 auditing columns, create_by, create_date, etc). So, for example, I can write a findByCreatedDate() function in my BaseDao and BaseHibernateDao classes.

PostgreSQL certainly does allow multi-column unique constraints. From the docs (http://www.postgresql.org/docs/8.1/static/ddl-constraints.html):



Hibernate has a <natural-id> you can use to identify your unique columns
(http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#mapping-declaration-naturalid)
(http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#query-criteria-naturalid)