<snip>

Yes it can be, it is the number of times the record was updated.

It is not the goal to outperform the database cache.  It is the goal to
outperform the total of query+object creation+mapping from resultset to
object+network latency to transfer the object.
When you have 1000 users pulling objects the relieved database,
application server and network resources can be considerable.

No, must be the latest updates.

It would be very fast to issue select version_nbr from your_table where
primary_key = ?

To further illustrate my point.  Take this real world example

table patient (patient_id, last_name, first_name, sex, dob,... etc for
40 fields).
table appointment (id, appt_date,... etc for 30 fields).
table orders (order_id, order_name, ... etc for 40 fields).
table results (result_id, order_id, result_name, etc. for 20 fields).

I pull up a patient record and it pulls in:

1 patient rows
8 appointment rows
80 order rows
800 result rows

All row data are mapped to an object which adds significant business
methods to the data.

To pull in that much data may take non trivial resources and at least
2-5 seconds.  The user can then browse, filter, sort, group and do many
operations on the local workstation.  All operations are fast since the
object data is held in memory.

However the user is waiting for a new set of results.  Every 10 minutes
they click a refresh button.  To pull in the same data is a wasteful
use of resources.  If you have 100 users simulataneously pressing
refresh then you have a significant performance bottleneck.  You would
need a very fast database server and many application servers to scale
and keep the same 2-5 seconds.  At some point you would probably need
to cluster the database.  This becomes very expensive and starts to
push the cost of the hardware so that many organizations cannot afford
it.

But take a step back and look at the problem.  For 98/100 of the
patients the data did not change.  Lets suppose that each order object
has a version stamp which is updated every time anything on the order
or underlying tables for the results changes.  A simple, single query
of

select version_nbr from orders where order_in (...) would identify
whether the local PC objects are still fresh or whether the object
needs to be extracted.

Now this would *never* work with a legacy system, there are just too
many possibilities that someone has written a query/batch job or
something that will update the database without updating the version
nbr.  But with a new system you can enforce it from the get go.

I agree dont tune till you need to, dont fix it until you have to, but
I know this problem is coming.
This is undoubtably less applicable to simple applications which use
resultsets directly but that is not where I am coming from.  The
complexity of the domain is significant and needs the DTO architecture,
fat objects etc.  There is a performance cost to that of course, which
is what I am looking to offset.