Hibernate/JPA DB Schema Generation Best Practices

Question

I just wanted to hear the opinion of Hibernate experts about DB schema generation best practices for Hibernate/JPA based projects. Especially:

1. What strategy

Answer 1

Like Bozhidar said, don´t let Hibernate create&update the database schema. Let your application create and update the database schema. For java the best tool to do this is Flyway. You need to create one or more SQL files with DDL statements which are describing your database schema. These SQL files are then executed by Flyway. For more information look at the site of Flyway.

Answer 2

Although disputable, I'd say that the answer to all 3 questions is: let hibernate automatically generate the tables in the schema.

I haven't had any problems with that so far. You might need to clean some field up manually from time to time, but this is no headache compared to separately keeping track of DDL scripts - i.e. managing their revisions and synchronizing them with entity changes (and vice-versa)

For deploying on production - an obvious tip - first make sure everything is generated OK on the test environment and then deploy on production.

Answer 3

I believe that a lot of what is being discussed or argued here should also be related to if you are more confortable with the code-first or the database-first approach.

Personally, I am more intended to go for latter and, making a reference to Single Responsibility Principle (SRP), I prefer having DB specialist handling the DB and an application specialist handling the application, than having the application handling the DB. Additionally, I am of the opinion that taking too many shortcuts will work fine at the beginning but create unmanageable problems as things grow/evolve.

Answer 4

1. It's always recommended to generate the schema manually, preferably by a tool supporting database schema revisions, such as the great Liquibase. Generating the schema from the entities is great in theory, but were fragile in practice and causes lots of problems in the long run(trust me on this).

2. In productions it's always best to have manually generated and review the schema.

3. You make an update to an entity and create a matching update script(revision) to update your database schema to reflect the entity change. You can create a custom solution(I've written a few) or use something more popular like liquibase(it even supports schema changes rollbacks). If you're using a build tool such as maven or ant - it's recommend to plug the db schema update util into the build process so that fresh builds stay in sync with the schema.

Answer 5

Manually, because:

1. Same database may be used by different applications and not all of them would be using hibernate or even java. Database schema should not be dictated by ORM, it should be designed around the data and business requirements.
2. The datatypes chosen by hibernate might not be best suited for the application.
3. As mentioned in an earlier comment, changes to the entities would require manual intervention if data loss is not acceptable.
4. Things such as additional properties (generic term not java properties) on join tables work wonderfully in RDBMS but are somewhat complex and inefficient to use in an ORM. Doing such a mapping from ORM -> RDBMS might create tables that are not efficient. In theory, it is possible to build the exact same join table using hibernate generated code, but it would require some special care while writing the Entities.

I would use automatic generation for standalone applications or databases that are accessed via the same ORM layer and also if the app needs to be ported to different databases. It would save lot of time in by not requiring one to write and maintain DB vendor specific DDL scripts.