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

Hi Gary,

Sorry about the late reply. It's just that some people (especially the ones paying my salary) has this funny idea that we should work also :)

[evolution stuff, snip...]

> All software suffers from the same problems of scalability and safe
> evolution - all of it.

Especially software that *only* uses strict mathematical rules and interact in wholly deterministic ways.

Strict predicate logic requires things to be so or not (true or false). In set theory, an element belongs to a set or not. That's it. There is no room for such things as evolution and human errors in such strict rule based systems. Roughly speaking, the relational theory can only handle static problems.

Now, I'm not saying that strict/pure logic or the set theory is useless, not at all. It has certainly succeeded as a nice method for building most of the software (and quality software too) we have today.

But that does not mean it is a silver bullet. There are a lot of problems out there that can't be reduced to simple logic and set theory.

For many applications (including distributed databases) it is better to model the information (and the processes that work on them, say agents) as a dynamic (say evolving history-dependent interactive) environment. In such systems the object identity is needed to keep track of object changes through time.

> Despite the almost religious zealotry imbuing many
> OO devotees, Objects and Classes don't solve the problem either.

The class (as know from Java, C++...) is an ADT mutated into something very ugly (I picture it like him Jaba the Hut from the starwars movie).

BUT, that does not conclude that object-orientation is bad or useless.

> Databases
> (of all kinds) offer a useful and (hopefully) usable abstraction for
> introducing a fundamental layering into system design and implementation
> processes.

Agree, but there are many more ways to layer things than to use strict logic.

> 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.

Exactly, we should investigate more time learning how to go beyond 'classical mathematics'.

> > 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, ...

That's also the kind of concurrency i'm talking about.

> > 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.

OO is still in its infancy. However, using method such as the relational theory only, and you got a dead end.

[snip...]
> >
> > 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!

That is not true. Who told you that?
Can you elaborate what kind of evolution you are taking about?

My math teacher also had this idea to 'torture' people until they believed that one could solve all problems using simple and logical explanations (i.e. pure/strict logic). Fortunately he screwed up (maybe because I was always sleeping while he was talking), and I found out later, before it was too late, that he was wrong.

IMO having only one point of view (or one way to do things) is bad, whatever it's the one the teacher has or the textbooks have or some theory has.

"Be very, very careful what you put into that head, because you will never, ever get it out"
(Thomas Cardinal Wolsey).

[snip]
> > 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.

You must be kidding. That's what a physicist would call a determinist or reductionist. What you write sounds to me coming from a software architect crossed with a newtonian or something :-)

As I have said before, networks, distributed object architectures and large-scale distributed databases are concurrent, asynchronous and non-deterministic all the way down (from the highest conceptual level we can think of, to the actual bits and bytes on the harddive). With these kind of systems it is impossible to specify an appropriate set of strict rules and predicates in advance. You can't 'control' such systems using turing machines on steroids like the relational database.

Roughly speaking, we need to handle non-deterministic splitting of computer resources (parallel computing, distributed systems, such stuff) and also non-deterministic be able to choice between protocols, rules/predicates and so on (at runtime). Also such systems are history dependent. That is, we need to be able to deal with multiply versions of our objects through time.

What I'm trying to say is, that some of the methods from the object world can help us solve these kind of problems. But it sure ain't going to work as long you relational people won't accept anything but strict newtonian kind-of logic and object people won't accept anything but 'rules of thumbs' techniques with no depth (or ad-hoc stuff as you call it).

I mean, how are you going to handle systems of the future with Codd's relations and all his strict rules and predicates? I really like to know that.

Don't tell me you want to build complex systems from the ground up using classical strict logic. You can't do that man. Such system will not work or perform in distributed and interactive environments.

Now, I'm not saying we should use some insane holistic theory of some kind. I'm just saying that only using logic (as Codd is using) will not solve our problems. Only using strict rule-based logic to create databases or to represent information is a dead end.

>
> > 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".

Really, you seem to hate them.

> 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).

Just because a theory don't uses mathematics in the strict sense does not mean that it is a bad theory or not a theory at all.

> > > 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!

Well, it would be nice if everything was that simple :-)

[snip.....]
> > 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?

No, I'm not saying that.

OO databases of today have many of the same problems as relational databases (and add some). And I will also to some extend agree with you that much of the OO stuff out there is ad-hocery. IMO this is mainly because most people are just to damm lazy and jump right on to the latest hype or newest crap technology they see. Many people (especially the once who takes decisions and those who create compilers :-) seems not to devote any time at all to understand what they are talking about.

However, IMO this problem is not about object vs relational or choosing between either a relational or object database. It's about using and *understanding* concepts from both worlds. People accepting one way only are doomed to fail. Also, people who want to separated the two worlds though some primitive logical model are doomed to fail ;-)

> > 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!
> ;-)

IMO that's the fundamental problem or dogma you just describe there. That people think there is a straight and narrow solutions to every problem.

As I see it, this discussion boils down to that of turing-machines and complexity. You can't solve complex problems (such as building a scalable, flexible and evolving information architecture) using some turing machine on steroids. IMO the relational database is exactly that.

Actually, I believe the core problem boils down to that of epistemology. That how we can develop methodologies and methods for solving problems that are better than what we have today.

If we don't do that (find better ways) we're doomed to live with all this crappy buggy and inflexible software we have today for the rest of our life. Then I would much prefer to be a gardener or maybe a taxi driver rather than a software developer :-)

IMO the 'best way' is that people (including mathematicians) should get into their head that 'there is no best way'. That's also why I like what Marvin Minsky is doing, because he argues that to build intelligent and robust software we must employ many approaches. Unfortunately that's a lot easier said than done. However, there are more and more people out there that have actual managed (to some degree) to go 'beyond traditional mathematics'. I pretty sure that these people will win in the long run, not guys like you ;-)

Jesper Received on Thu Oct 25 2001 - 09:43:43 CEST