Re: caching design patterns
Timasmith wrote:
It seems to me that to each a truly performant enterprise level
application with thick client functionality (a lot of it) you really
need to use caching to the nines.
....
What if I have medium sized DTO business objects that can be retreived
with a version number from the database. No data can be written
without updating the version number.
When it comes to pulling data in I simply send out my primary key +
version number and either a new object or the locally cached one is
returned.
Daniel Pitts wrote:
Actually, I've found that the ability to add caching is important for
scaling, but actually worrying about caching when it isn't a concern
can cause a lot of problems. Its along the lines of premature
optimization.
Write it without caching. If things run slowly, profile it and find
out where (don't assume it is a caching issue). If it does appear to
require cachine, refactor it in. You do know how to refactor, don't
you? :-)
....
Karl Uppiano wrote:
I don't think he means ignore until the problem strikes, but test and find
out where the problems are, and fix them. Speculative optimization is the
cause of some of the most unreliable, over designed, overly complicated code
around. Build the simplest thing that will possibly work -- then -- make it
work, make it right, make it fast.
I have found that version numbers in a database record greatly complicate the
db - is a version number *really* part of the data model?
Also, databases have caches, at least all the products I've considered using
for real applications do. Are you likely to outperform the database cache? By
enough to matter?
Caching is useful for things like result sets, where you don't want to go back
to the database to retrieve data the *client* knows it hasn't changed.
The problem of information latency is subtle and not addressed easily by
simple bandages. Consider for each query how much latency it can tolerate -
must it have absolutely the latest available data incorporating all other
clients' changes, or can it work for a while with data from a few
(milli)seconds ago?
Stay away from version information in a database record. How will you know if
a client's version is stale without doing a database query anyway? Is it
really worth great complications in update, insert and delete logic? I
predict it won't solve your (perceived) problem anyway.
There might be some value somewhere to version (or other history) data in a
transaction table's row, but I haven't seen it. (History tables are a whole
separate subject, but even there you don't have version data, just temporal
information.) I wonder what Mr. Celko thinks of the idea.
- Lew