Re: The Fact of relational algebra (was Re: Clean Object Class Design -- What is it?)

Hi Jesper,

Thanks for the reply. I consider it a great privilege to be able to freely communicate with such knowledgeable and erudite people as yourself.

<snip>

> As an example take something like quantum computing, it works perfectly
fine
> in theory! However to make it work in 'real life' we need concepts such as
> quantum error correction. Also such error correction mechanisms are common
> used in biology. Real life stuff don't seem to know about mathematics.
Like
> the real world, the behaviour of computer systems is teleonomic, they will
> evolve into future state and structure, which does not exist yet.

Quantum computing is not something I would like to venture an opinion on - but (to paraphrase from his Holiness) - stop it or you'll go blind!

> I see the OID stuff as a kind of relational theory error correction
> mechanism.

And I see it as an "error introduction" mechanism - or perhaps an "error invitation" mechanism.

> And of course, it should be transparent to the user. That is, it
> is not the relational theory that has errors, but the humans that designs
> and uses the system -- "programming is human activities, forget that and
> every thing is lost" (I believe it was Bjarne Stroustrup that said
something
> like that).

The relational "theory" is not where the errors lie. It is firmly and securely based on sound mathematical axioms and logic. The implementation is where the problems lie. Of Codd's original twelve rules, I believe that no commercial RDBMS ever managed to implement more than six. This is in fact, the Achilles heel of relational database - the fact that a usable implementation of the theory has not yet been created (afaik).

> Okay, from a logically point of view I believe you are right, that the
> application/user should see nothing but a logical and 'perfect world'.
>
> However, the main problem with relational database designs is that they
> can't scale and evolve, because we are forced to use this central 'big
> brother' to oversee and control every operation (to enforce consistency of
> the data or whatever you call it).

All software suffers from the same problems of scalability and safe evolution - all of it. Despite the almost religious zealotry imbuing many OO devotees, Objects and Classes don't solve the problem either. Databases (of all kinds) offer a useful and (hopefully) usable abstraction for introducing a fundamental layering into system design and implementation processes. This layering can be perceived from certain perspectives as restrictive and unproductive - from other perspectives it offers vital and fundamental features for auditability and control. And it _should_ _increase_ the possible rate of evolution and levels of scalability. The fact that it might not always succeed in doing so is due to the undeniable fact that software development processes are still in their infancy - we all have _much_ to learn.

> You're talking about concurrency, but the fact is that the relational
theory
> does not have a solution to this problem (actual, it's part of the
problem).
> Relational database is build up around this 'centralize dogma' and that's
> what makes them inflexible and slow.

Yes, but concurrency not just in the sense of concurrent users though. but in the sense of concurrent applications, designs, systems, ...

> Roughly speaking, the relational databases of today are weak because they
> don't take into account concepts such as theory of complexity and
evolution.
> They are weak, because they rely on a strict mathematical theory that
breaks
> down very easily in real life environments.

At least there _is_ a theory, which is a helluva lot more than can be said for any other aspect of software development - including and in particular object-oriented techniques.

> [snip]
> > > In short, no one must never ever be able to change the values making
up
> > the
> > > relational key. If they do so, the concept of strong object identity
is
> > lost
> > > in references cached outside the database.
> >
> > Exactly, because the relational key _is_ the "object identity" (sic).
> > Changing the key makes it an entirely _different_ "object".
>
> Yes, and how do we control that? Your theory don't support the concept of
> evolution of any kind, so we really shouldn't change such key ever, which
is
> of course impossible.

Au contraire, Relational theory offers a complete and sound model for safely evolving the contents of relational databases. Every thing else is just ad-hocery!

<snip/>

> If your relational theory is so 'perfect' (and can handle all kinds of
> problems), why is it that the software world is in the stone age then???

See above. Certainly not because of relational theory - quite the opposite imho.

> What is the reason that you're so strongly on the relational side? I
really
> dont understand that.

Because it starts from a mathematical basis, and works up. As I said before, all else is just ad-hocery.

> I will strongly argue that of being one both sides (or many sides) and we
> will win this war (against complexity and stupid users :-). Being on one
> side, and you'll just run into a lot of trouble.

I love objects - I have studied and practised object-oriented programming for over a decade now, in many different languages and guises. I _am_ on both sides of the "war". It's just that I hate to see people bemoaning "relational" without any better theory to replace it ! (or any theory at all for that matter).

> > that the database itself has to provide support for them. That is
> entirely
> > analagous to the "horse riding the jockey".
>
> Hmmm, I can't see how that is possible. The two worlds must work together
> somehow.

O-O for application development - Relational for data storage. Simple!

> I know this is a little far out, but try listen to this little story:

<snip some fairly irrelevant stuff about Turing machines being too slow to be useful>

> This little and great paper (The Paradigm Shift from Algorithms to
> Interaction) from Peter Wegner explains the problem very nicely I think.
> http://www.jeffsutherland.com/papers/wegacm.pdf

Sound interesting - thanks!

> Now, my claim is that the relational theory (with its strict constraints
and
> it's value based object identity concept) has many of the same problems as
> turing machines.

On that may well be correct, if indeed, it has been performance considerations that have prevented the relational model from being properly implemented.

<snip/>

> Basing any large-scale information system on a central "big brother" (such
> as a relational database) that is to control and oversee every single
little
> data operation is doomed to fail! Such centralised rule-based architecture
> is insane because it limits the system to scale beyond the capabilities of
a
> single computer. I'm convinced that the centralised database approach to
> information sharing as we know it today will very soon (hopefully) die a
> much deserved death.

So it is _not_ "Relational DBMS" you are against - but _any_ DBMS in fact. I admit there are times when I am inclined to agree with you on that one! <g> But if there is to be a database - relational wins imho!

<snip/>

> To create large-scale distributed systems (say, interactive real-life
> evolving environments) we need *more* than just a bunch of static
> mathematical laws. For example to succeed object replication and dynamic
> load-distribution we need (along with a lot of other things) the concept
of
> strong object identity. In short, we need a lot more sophisticated
> architecture that can adapt and take decisions at runtime what protocols
and
> rules to use.

For sure. But these are, or at least should be, orthogonal to the technology employed inside the database, which may _internally_ use object-IDs and suchlike for all sorts of things - but should never expose them to applications.

> As Marvin Minsky once said "There is no one best way to represent
knowledge,
> or to solve problems, and limitations of present-day machine intelligence
> stem largely from seeking "unified theories," or trying to repair the
> deficiencies of theoretically neat, but conceptually impoverished
> ideological positions." (From paper: "Symbolic vs. Connectionist":
> http://www.ai.mit.edu/people/minsky/papers/SymbolicVs.Connectionist.txt)

Where do you get all this stuff from? (Thanks ;-)

> The theory you relational dudes have is IMO a 'relational tar-pit', a
place
> where anything is possible but nothing of interest is practical. The
harder
> you struggle to get any real work done, the deeper its inadequacies suck
you
> in.

Oh, and OO databases are a stroll in the park to implement, scale infinitely, distribute perfectly - are a dream to program with, don't lock you in to any particular language or vendor, and in all probability will solve world hunger before the end of the decade - yes?

> But don't tell anyone that I just said that, because I'll properly get
> into a lot of trouble :-) Just as much trouble you guys ought to get into
> posting to a newsgroup named comp.object.database claiming that the
concept
> of object identity is useless ;-)

<GG> It's just that we know that you object dudes are equally as broad-minded as ourselves, and enjoy the opportunity to get yourselves back on the theoretical straight and narrow, after having been seduced and led astray by all those object heresies out there! ;-)

> Anyway it's an interesting discussion.

Sure is!

cheers,

gary Received on Mon Oct 22 2001 - 12:45:51 CEST