> From: Marcel Weiher
> > The DBA's can watch how the database is being used and tune this
> > (i.e. partition the data and move it to another CPU, etc., etc.).
> 
> To some limited extent, yes.  But they can't work miracles, and
> neither can the DB.  In fact, if you know your access patterns, you
> can (almost) always do better than the DB, simply because there are
> fewer layers between you and the code.

[Note: I appear to be getting a slow and incomplete feed from squeak-dev
- someone else may have said what's below or the discussion may have
moved on.  My apologies if so.]

*If you know your access patterns*, I agree.  I suggest that in
many/most practical business applications you do *not* know your access
patterns, because the data is at the core of the business and will be
used in unexpected ways over time.  The old schema will change slowly;
new pieces of schema will be bolted on at the edges as new applications
are accreted; many, many ad-hoc reports will be written that need to run
"fast enough" when they are required; and different functional areas of
the business will wish to view the data in their own way.  Optimising
for any one set of access patterns counts as premature optimisation, and
will come back and bite you later.  I claim that one of the advantages
of a normalised TP database is that it is agnostic about its access
patterns, and that indexes (and indexed views) can be added later and
changed dynamically to improve response times as the access patterns
change over time.

RDBs are "good enough" for quite a wide class of problems, and most
sensibly-designed relational databases have gentle fitness curves - as
the requirements change over time (which they do), there are
comparatively few changes that completely break the database.  By
contrast, a highly-optimised storage structure is fragile - a
requirements change may completely screw the optimisation, or be screwed
by it.  I don't want "right", I want "good enough for the job".

		- Peter