Re: Mixing OO and DB

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 13 Feb 2008 11:54:26 GMT
Message-ID: <STAsj.5512$J93.5161_at_trndny08>


"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:47b24e69$0$85790$e4fe514c_at_news.xs4all.nl...
> David Cressey wrote:
> > Robert Martin wrote:
> >> Victor Porton said:
> >>
> >>> I know both object oriented programming and DB (SQL). But it seems
> >>> that these are incompatible. Or may somebody advice how to meddle them
> >>> together?
> >> The concepts are orthogonal. Objects are not tables. Tables are not
> >> objects. The many efforts to try to force tables and objects together
> >> always cause trouble. Things work better when you recognize the
> >> benefits of tables, and the benefits of objects, and use each where
> >> they belong rather than try to force one to use the other.
> >>
> >> Tables expose data and have no behavior. Objects hide data and expose
> >> behavior.
> >
> > I have a different understanding.
> >
> > Objects do not always hide data. Specifically, they pass messages to
each
> > other in the form of data. Going further, objects do not "see" the
behavior
> > of other objects. What they see is the data, written into messages,
that is
> > the result of behavior. Seeing the result of behavior is not the same
thing
> > as seeing the behavior itself.
> >
> > One could do a data centric analysis of an object world, by analyzing
the
> > data passed among the objects in that world. Such an analysis would be
much
> > more like the kind of analysis one makes of a database. Or, perhaps
more
> > likely, analysis of a set of information requirements that is to be
filled
> > by a database not yet designed.
>
> In ISAC (Information Systems Analysis of Change, an originally
> Swedish school on Informatics, late 70's) there is a useful technique
> called "precedence analysis", with 'Y'-diagrams (like genealogy
> trees).
>
> It disregards all computations except as confluence nodes for data.
> It goes backwards. Not "where does it go to", but "where does it come
> from". Very push-through in situations with mutliple interacting (say
> semi-autonomous) systems. I have never seen a tool supporting this -
> it would come in handy sometimes.

Your description reminds me very much of something I saw years and years ago. It was in the area of field service engineers diagnosing a malfunctioning system down to a single board or a single component on a board. The documentation of the signals being passed around by the board or backplane were always organized by "where does the signal come from" and gave information about "where does the signal go?"

But the field service engineers nearly always traced signals "backwards". That is, they would start from the place where the malfunction was observed, and work their way upstream back to the point where the malfunctioning component had first injected a bad signal into the system.

The way the documenters had organized the signal documentation was almost worthless to them. And the way the FSEs worked was incomprehensible to the documenters.

Perhaps precedence analysis is likewise more useful for determining why a given system does not work than it is for synthesizing a system that will work. Received on Wed Feb 13 2008 - 12:54:26 CET

Original text of this message