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

David Corking lists at dcorking.com
Tue Jan 2 22:05:19 UTC 2007


On 1/2/07, Howard Stearns <hstearns at wisc.edu> wrote:
> There are also problems for which pencil and paper really aren't suited
> for. Same for RDBMS. They can be made to work with the great expenditure
> of resources, chewing gum, bailing wire, duct tape, vise grips, etc....

> What I'm trying to do -- and of course, this isn't a Squeak question at
> all, but I hope it is a Squeak community question -- is try to learn
> what domain a perfectly running RDBMS is a good fit for by design,
> compared with a perfectly running alternative (even a hypothetical one).

I am not clear what you mean by "good fit by design"

When you asked in an earlier message "whether the math techniques that
were developed to  provide efficient random access over disks 20 years
ago are still valid" were you referring to the math  techniques
relational model?

If so, my hunch is that you are framing the question upon an incorrect
perception of the purpose of the relational calculus.   My
understanding is that the calculus, or specifically SQL, is a _problem
statement  language_ , a way for engineers to specify what needs to be
done, leaving the computer to figure out how to do it.

I wasn't doing this 20 years ago, but my reading of history is that
engineers knew perfectly well how to make efficient use of disks, and
when their employer bought the leading RDBMS they got a slow layer of
murky proprietary code, with a shiny standardised data model and API.

In other words, RDBs make data access slower, _but_ make engineering
easier for some problem domains.

David



More information about the Squeak-dev mailing list