Re: Objects and Relations

On Feb 18, 11:45 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Walt wrote:
> > "David BL" <davi..._at_iinet.net.au> wrote in message
> >news:1170723701.183064.263580_at_h3g2000cwc.googlegroups.com...
>
> >>On Feb 6, 5:01 am, Kenneth Downs <knode.wants.t..._at_see.sigblock>
> >>wrote:
>
> >>>Walt wrote:
>
> [snip]
>
> >>I note that systems based on RM provide the means to manipulate the RM
> >>state. So it doesn't seem quite right to say that RM is about
> >>passive state and OO is about active state. Remember as well that
> >>most objects don't host their own threads and therefore are passive
> >>(meaning they only do things when a thread calls their methods).
>
> >>I claim that the distinction between OO and relational has a lot to do
> >>with the question of whether entities are inside or outside the
> >>abstract computational machine, noting that 1) secondary storage is
> >>part of the machine so persistence has nothing to do with it, and 2)
> >>at the system level both relational and OO based approaches are
> >>"active" so that has nothing to do with it either.
>
> I find the above lacks insight in a profound way. The RM is a formalism
> that systematically applies predicate logic to the task of managing
> data. OO is an ad hoc computational model based on an arbitrary set of
> features useful for creating large unpredictable state machines out of
> small predictable state machines.

That distinction is correct. However my point was not to describe the trivial, self-evident differences between OO and RM; even Bob can manage that :). Rather, it has been to come up with a strong criterion for determining when each is appropriate in practice. This is a far more challenging problem.

The fact of the matter is that "data" is not so different from "state", and both OO and RM are stateful. There is no question that OO *can* be used to represent data models and to manage those data models. It is also true that RM+RA *can* be used to help create state machines. There is nothing at all limiting the potential scope of RM+RA if it is extended with a suitable language to make it Turing complete.

There is nothing in Bob's above distinction to stop OO programmers from ignoring RM all together, or use O/R mapping. There is also nothing to stop RM from being used in problems for which it doesn't appear well suited, such as string or image processing. I note that strings and images can be regarded as "data", and string or image processing algorithms can be expressed in RA plus some language extension. There is nothing in Bob's distinction to suggest that RM +RA isn't a perfect fit for these domains. In fact Marshall believes that is the case.

My aim has been to come up with a criterion that makes good unambiguous design decisions during the design process. Received on Mon Feb 19 2007 - 13:19:25 CET