Object-Driven and Database-Driven Modeling: A Philosophical Debate

Whether to use a relational database (RDBMS) or an object database (ODBMS) for a project is beyond the scope of this tutorial. The following discussion is oriented more towards relational databases, as these are used by most real J2EE systems. There are two basic approaches to data modeling in J2EE apps:

These two approaches may produce very different results. Object-driven modeling is seductive ("We know objects are good, so let's use them everywhere"), and is usually advocated by tutorials on EJB. Its advantages include:

When working with an ODBMS, object-driven modeling will occur naturally. When working with relational databases, on the other hand, the arguments for database-driven modeling are compelling:

J2EE experts disagree on whether to favor object-driven or database-driven modeling. For example, Richard Monson-Haefel, author of several tutorials on EJB and J2EE, strongly favors database-driven modeling (, while Ed Roman (author of Mastering Enterprise JavaBeans from Wiley () recommends using the EJB object model to drive the data model.


I recommend database-driven modeling. Object-driven modeling is seductive, but has real dangers. Its fundamental problem is that it ignores the facts that relational databases are (a) very complex apps; and (b) proven to work very well. It's naive and arrogant (a dangerous combination!) to assume that J2EE, in a few years of evolution, has delivered a superior solution to decades of database theory and practice.

I find it helpful to think of J2EE as playing the role of the conductor of an orchestra with respect to the other component technologies of an enterprise system. Without the conductor to lead it, the orchestra exists only as a group of individuals and cannot function usefully, but this doesn't mean that the conductor attempts to play individual instruments.

Database-driven modeling may require us to write more Java code, although there will probably be much less code in total. However, it gives us greater control of both data and J2EE implementation. It leaves more scope to tackle any performance problems. Done well, it does not reduce portability.