I am going to be building a new application and I am strongly thinking about using Hibernate in it. What is best practice and why, build the db first and maybe reverse engineer to objects in eclipse or build my POJOs and mappings and use either an ant task or something to generate my database schema based off the object model and mappings?

My app is going to be a standalone swing app using Java 5 and currently will only need to support one db but will support others in the future.

Build the POJOs first. Let Hibernate do the down in the weeds stuff. In your cfg.xml you can set a property that tells hibernate to change the db based on your POJOs. USE IT. The great thing about Hibernate is that you can spend your time thinking about what the system should do and not how to persist the data. There are people that love databases that think you should build the schema first and then "you have all the data". Don't believe it. If the POJOs and the system work the way you want, then it is hibernates job to accommodate you. Whitch it does quite well. If you start with the DB them you make compromises that affect the domain model. Make the DB bend to your will not the other way around. Also, I have used annotations for the first time recently. MAN, that is the way to do things. I needed a little class the other day and spent about 5 minutes writing it. Then I took about 1.5 minutes to annotate it. BOOM up and running in no time and didn’t compromise a bit!!!

i woud start with the DB. The reason is that when you design a db, then you will think about wat is a good db design. This help's you to build fast and stable application.

After then I start with the application design. the cap between this two desing I fill with the dao pattern and the or mapper (in this case hibernate)

hope this helps you a little

rgds pfenn

Anyone else have thoughts here maybe some of the experts out there :-) I am concerned that if I go the way of modeling the POJos and let hibernate generate the table structure I will get bad performance or bad structure that could cause problems later.

that depends on how you design the pojo's.
and how are the relation between. And also how big will your datastore be.

The database is optimized for relational structure and not for object oriented. thats the reason why I prefer a good DB Desing.

rgds pfenn

you could start with the mapping files, then generate both the db and the java objects, and if you don't like the way things look then fine tune it from there. but it's a quick way to give you something to work with at least.

By dismissing good software design with a COULD that you can't backup, you walk down a path of compromises that hibernate has been design to prevent you from having to make.

Good luck

Here, we always start with the mappings, and then we generate the POJOs *and* the database schema from there.

Really, though, you will wind up learning an enormous amount about both Java performance issues and database performance issues. We certainly have. (A Java example: don't have thousands of children in a Hibernate collection, Hibernate adds very little value and often tries to load them all, which you never want. A DB example: make sure you add indices on foreign keys, because Hibernate won't auto-generate them.)

So the moral is, it doesn't so much matter where you start -- you have to understand both sides and their performance problems either way. Just make sure that whatever you do, you write the system in an incremental way, so you can test it as you go and find any performance problems early. Never, ever go off and spend months writing a huge pile of code! Write a REAL SMALL pile of code, performance test it, and then add to it and repeat ;-) That's the real way to avoid digging yourself a deep hole that you didn't see coming.

Cheers,
Rob

Ther are two good ways if you care about modeling:
1. Define informal model ( ER ) and generate both DB shema (formal model) and data access adapters (POJO,DAO, ...). AndroMDA helps in this case.
2. Define formal model (DB schema) and generate adapter code from this model. Hibernate tools, Midlegen.

"1" is better if you do not want to care about normalization stuff and trust your tool. "2" is better if you can define better formal model than tool can generate from conceptual model (without ERD,UML).

If you do not care about modeling then you can generate formal model from code.