+1
From: "Peter Crowther" Peter@ozzard.org Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@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