Architecture purity vs. Resource access optimization

Question

I'm working on a rather complex application with a number of pattern implementations like DAO and Service, but I'm not an experienced developer, so I often find myself in situation, when I can't decide, whether to pursue more strict pattern implementation, or break it in favour of resource access optimization.
For instance, if I have an object which is stored in database, or a JCR repository, it'd be nice to have a DAO+DTO and use DAO.save(dto) and dto = DAO.load() to load and modify the object. However, in many cases it's just one property of the object that needs to be modified, so I have methods like DAO.updateSomeValueOf(dto). I don't like those methods very much (:
So I'm wondering, are there some sort of articles or best practices explained to read on the web, (or even in a dead-tree form) to understand this problem better and don't feel so bad each time a DAO has to be modified?

Answer 1

s.p. wrote:
Yes, you're most probably right. This is something I'm doing following an advice from a senior developer ("it's best to have the least number of database queries in almost all cases"), though now I'm actually thinking this is exactly what's called "premature optimization" (if it is in fact an optimization).
What does that have to do with your original statement though?
Say you have a customer and want to update the address and only the address (street).
The choices are write the entire customer record or write just the address.
In both cases there is one write. Only one.
Conversely say you want to update the address and zip code.
The choices are
1. Write the entire customer record
2. Write the address and zip
3. Write the address then the zip
Then 3 requires 2 writes. Thus not as good as 1/2.
However, all of the above is completely moot. It does not in fact matter if you did do 3. The reason is simple - there is no business case where you are going to be updating (versus creating) customers in such volumes that this would ever have any impact even in a business with a huge (millions) of customers.
Conversely that doesn't mean that you should ignore the implications. There can certainly be cases where minimizes writes is a good idea.
Of course none of this addresses queries rather than writes either. Most businesses will do far more queries than writes. Some businesses (think google) do vastly more queries than writes. Probably really not a good idea to query the name, then query the address, then query the street. However in some cases even then separate queries are good ideas. For example if you query a customer you would not want to query all of the orders for the customer even though you know that the next query will in fact want a order (but only one.)