I was recently asked this question and I am not sure of the right answer to the question. Using O to R mapping tools we have objects being mapped to tables in the databases. The question is do we build the object layer first without considering the database schema or do we build the database schema first without considering the object model ? What about a third approach-build the object model separately and the schema model separately and then find adapters/bridges to map calls from the object model into the schema ?
- OR Mapping by Daniel Freitas on November 24 2004 07:59 EST
- OR Mapping by Thibault Cuvillier on November 24 2004 09:54 EST
- Design issue by Kris Huggins on November 24 2004 10:21 EST
That really depends. When I work with Hibernate (an object persistence framework) I build my object model, map to hibernate, and let the tool generate the schema for me. I don't care how the data is saved on the database. I just want my objects being persisted.
But sometimes you can't use this aproach for many reasons (specially if you work on a corporate company).
On the current project I'm working, we modeled the schema first and built our object model on top of it. Needless to say, our model did not become full OO.
But when I can, I go for the object model and create a schema for it.
The third aproach (adapters/bridgers) is common when you already have data saved on your corporate database (full of nonsense fields/ugly implementation ;) ) and have to build an OO application.
Does this approach allow you to tune and optimize the database schema ? When we used a OR tool on our project we created the object model independent of the schema and then ended up with a poorly performing database. The OR tool generates the queries(either that we create our own named queries) which may perform poorly vis a vis the database. The adapters/bridge approach allows one to tune the object model independently of the schema layer.
As I said, you cannot always use this aproach. On the projects I used Hibernate, we had no performance problems.
If performance is critical, you can always manage your own dependent DB queries, taking full advantage from the DB features.
On the project I'm engaged now, I couldn't model full OO. People had know-how on a previous version of the software and wanted to have the schema and implementation as close as the earlier version. So I had to do lots of proceduring code.
You cannot focus only on object model, and have to design yourself the DB schema to optimize it in term of performance.
OO and db schema design are a top-down (OO) and bottom up (DB) design processes. The join is the O/R mapping.
In term of performance, it may be more efficient to create DB views to handle a part of the O/R mapping, or to use some stored procedure for critical queries or update.
If the application you are working on is not critical in term of performance generate the DB schema.
Forget your bridge stuff, an O/R mapping tool will save you a lot of time.
My 2 c.
You need to focus on your domain model before you focus on how to persist it or represent it in code. Some find it difficult to separate the two concepts. If your domain model consists of Customers, Orders, Line Items, & Products, describe what it means to be a Customer, order, line item and product and how they are related. When this is done your database schema and object model should fall into place.
My opinion on java objects: Use java objects to model how you interact with the database, not to model how you want to think of your domain model while your programming. If everything is done right then the two should be the same, but if you start trying to model your objects a little differently then how they are persisted in the database then things will be confusing and complex.
When you say domain model i presume you are referring to a UML term. That would mean a model of any relation to a particular programming language. It is still object oriented -it uses concepts such as inheritance, interfaces, abstract classes and patterns. Is that correct ?
Domain model might not be the best term, but yes, UML is one way for defining what I'm calling your domain model. You really need to think of things outside of Java Objects and database terms before you start defining the database and java objects. You should describe customers, order, products, etc. without consideration to the implemenations details at first. Then you can define the relationships of each. A customer has orders, etc.
The next step is where people start to differ. If a customer has orders then people want to create a customer java oject that has a collection of order objects. That's fine & dandy, but needs to be custom coded and is sometimes difficult to persist in a relational database. It is my opinion that your java objects should model database tables and not "domain objects". Your domain object definitions and relationships will define your database model as it always has, then your java objects will model these tables. I am currently working on a tool that will autogenerate these java objects from the database definition in a value object/DAO paradigm. It will likely show up on http://www.krishuggins.com at some point, but not likely until after the holidays.