Question

This is a very simple question that applies to programming web interfaces with java. Say, I am not using an ORM (even if I am using one), and let’s say I’ve got this Car (id,name, color, type, blah, blah) entity in my app and I have a CAR table to represent this entity in the database. So, say I have this need to update only a subset of fields on a bunch of cars, I understand that the typical flow would be:

1. A DAO class (CarDAO) – getCarsForUpdate()
2. Iterate over all Car objects, update just the color to say green or something.
3. Another DAO call to updateCars(Cars cars).

Now, isn’t this a little beating around the bush for what would be a simple select and update query? In the first step above, I would be retrieving the entire object data from the database: “select id,name,color,type,blah,blah.. where ..from CAR” instead of “select id,color from CAR where …“. So why should I retrieve those extra fields when post the DAO call I would never use anything other than “color”? The same applies to the last step 3. OR, say I query just for the id and color (select id,color) and create a car object with only id and color populated – that is perfectly ok, isn’t it? The Car object is anemic anyway?

Doesn’t all this (object oriented-ness) seem a little fake?

Answer 1

For one, I would prefer that if the RDBMS can handle your queries, let it. The reason is that you don’t want your JVM do all the work especially when running an enterprise application (and you have many concurrent connections needing the same resource).

If you particularly want to update an object (e.g. set the car colour to green) in database, I would suggest a SQL like

UPDATE CAR SET COLOR = 'GREEN';

(Notice I haven’t used the WHERE clause). This updates ALL CAR table and I didn’t need to pull all Car object, call setColor("Green") and do an update.

In hindsight, what I’m trying to say is that apply engineering knowledge. Your DAO should simply do fast select, update, etc. and let all SQL “work” be handled by RDBMS.