Database Agnostic Application

Question

The database for one the application that I am working on is not confirmed yet by the business.

• Best guess is Oracle and DB2.
• What I've heard is initially the project will go live with DB2 V9 and then to Oracle 11g.

We are using Spring 3.0.5, Hibernate 3.5, JPA2 and JBoss 5 for this project

So what are the best practices here going into the build phase and test phase?

1. Shall I build using DB2 first and worry about Oracle later (this doesn't sound right)?
2. Or, shall I write using JPA (Hibernate) and then generate the database schema?
3. Or something else?

PS: I've no control over the choice of the DB, what and when, as these are strategic decision made by people sitting in nice rooms getting fat cheques and big bonuses.

Thanks, Adi

Answer 1

Obviously you are loosing the access to specific features of the database if you are writing your application database agnostic. The database is, except for automatic optimizations done by JPA and Hibernate, reduced to common features. You have to set some things to automatic and trust JPA/Hibernate to do it right that you could set specifically if you knew the database (e.g. id generator strategies).

But it seems that the specific developer features of the database are not relevant for the decision so they can't be relevant to the application. What other reasons may influence the decision (like price, money, cash, personal relations, management tools, hardware requirements, existing knowledge and personell) can only be speculated about.

So IMHO you don't have a choice. Strictly avoid anything database specific. That includes letting the JPA/Hibernate generate the schema (your point #2). In this project setup you shouldn't tinker with the database manually.

Well... sadly there ARE some hidden traps in JPA/Hibernate developement that make it database dependent (e.g. logarithmic functions are not mapped consistenly). So you should run all your tests against all possible databases from day one. As you write "Best guess is..." you should just grab any database available and test against it. Should be easly setup with the given stack.

And you should try to accelerate the decision about the database used, if possible.

Answer 2

Just "write using JPA (Hibernate)" develop it to be de database agnostic. Put all you business logic in java code not stored procedures.

If you are using spring you don't need jboss you could use just tomcat, about a quarter of the foot print, and much simpler imho.

Spring vs Jboss and jboss represents all that is bad, while spring represents all that is good in Java enterprise development

Answer 3

We have add this issue and had to migrate late in the project, leading to a lot of extra works, frustrations and delays.

My advise is to define an abstract layer. Go to the point you may have a data model without any database, say with tables or text files.

Then when you have to switch to some database, you can optimize for it, while staying free to continue application development on any already developped model. So you don't delay the developpers on the app while one is tuning the DB2 layer. When everything is duly validated, the team can switch on it.