Hibernate : schema export in real world?

im curious about using schema export fully for my next project. I see it as a very helpful way to really deal with the objects and not the underlying databases. Just create and annotate th开发者_JAVA技巧e models, and then export it.

But from the habit of creating the tables first and then the model objects, i have doubts about using schema export fully. This is mainly because i'vent really delve deep into hibernate. But im still curious whether this list of area will be a problem when using schema export. Please share your experiences ..

1. Relations between table
2. Surrogate / Composite primary key support
3. Re-exporting will recreate all the databases, when i just want to export some models out of many ?
4. Others i couldnt think of at this time

Thank you

Personally I don't like exporting DDL for the following reasons.

1. The database is probably one of the most critical bits of infrastructure in applications, trusting the DDL generation to hibernate means that you have to inspect all the DDL that is generated by hibernate to ensure it is all okay, the inspection process is just as time consuming as writing the DDL.

2. When it is time to release a new version of the application you will have an existing database in place, and therefore you might want to use alter statements, and have a upgrade-to-version-x.sql script to modify an existing database to make the new database work with the new version. At this point automatic DDL generation won't help you since the annotated hibernate class only causes CREATE statements to be generated and not ALTER DDL statements.

3. The Hibernate/JPA annotations fall into two categories, logical and physical. Logical annotations would be things like @Entity, and physical annotations would be things like @Table, @Columns ... etc. There is not enough attributes defined on the physical annotations to precisely control the database types that are generated for the SQL. For example, say you have a column which contains a Date and you are using @Column,@Temporal annotation on it, there is usually more than one database data type that fits, trusting hibernate to pick the default is probably not a smart move.

4. There are always database specific best practices that hibernate will not be aware of but a DBA will be aware of. For example, if you want to create an index there is no way to specify that in the hibernate annotations, or to specify what type of index to create, such as B-Tree, Bitmap ... etc. If the JPA/Hibernate annotations were enhanced to allow you to specify all the options that you can specify in database specific DDL then the annotations will be more complex than the SQL since the the SQL is very well built Domain Specific Language and the annotations will never be as good as SQL DDL, they will be more wordy. All you end up doing is shift complexity around without reducing it. Think of all the XML based configuration languages that you have run into that eventually add more and more complexity until the resemble a real programming language complete with xml based loops, if statements, variables ... etc

5. If the application grows and is a successful business app with a lot of data you will eventually need to hire a DBA to tune, optimize, mirror the database ... etc DBA will know the best practices for their database but may not necessarily/probably don't know Hibernate, which will make life more complicated for the DBA. There are many changes that a DBA can make to the database that don't impact the hibernate based java code, do you really want the DBA to change the hibernate code to change the database setting. Once the DBA changes the database settings now you have two versions of the database the exportable version from hibernate and the production one, which is the real one?

6. Database design best practices and Object Oriented Design best practices are not the same. Designing the database from the objects will potentially mean a great OO design but not such a great DB design, designing the DB first and then the Hibernate Object Oriented code might mean a great DB design but not such a great hibernate / OO design. Philosophically I prefer to write DDL by hand to put myself in database design mode rather than OO design mode. In a successful app the database design might outlast hibernate by many years. Just because hibernate is the only thing talking to the database today does not mean that it will be the only thing talking to the database in the future. So I tend to err on the side of optimizing database designs using database design best practices rather than OO best practices.

7. Hibernate / ORM is leaky abstractions, there is no way to hide the fact that you are dealing with an SQL database from the developers, if your developers don't know SQL very well they will likely, use hibernate in ways that will make the database a bottleneck. Personal experience training people on hibernate tell me that you must understand SQL even better to use Hibernate effectively. You need to be able to examine HQL or some other object query language and mentally translate to SQL. You will need to know when it is okay to map relationships and traverse them vs using a report queries. You will need to understand why the loss of JOINs on queries is such a problem. I am big fan of ORM/Hibernate and I can use it effectively but I find that many developers underestimate the complexity/intricacies of using ORM tools like hibernate.

8. The only exception that might cause me to export Schema's is if I am writing a throw away prototype and I don't know the database specific DDL very well. But I have not run into many throw away prototypes that did not become permanent all of a sudden.

These are my reasons arguing against DDL generation from Hibernate annotations. I hope others will chime in with their thoughts and experiences.