RE: relational for what? [was: Design Principles Behind Smalltalk, Revisited]

+1

>From: "Peter Crowther" <Peter <at> ozzard.org>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev <at> lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev <at> lists.squeakfoundation.org>
>Subject: RE: relational for what? [was: Design Principles Behind 
>Smalltalk,Revisited]
>Date: Thu, 4 Jan 2007 08:28:49 -0000
>
> > 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
>

_________________________________________________________________
>From photos to predictions, The MSN Entertainment Guide to Golden Globes has 
it all. http://tv.msn.com/tv/globes2007/?icid=nctagline1