Re: Mixing OO and DB

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 13 Feb 2008 14:15:58 GMT
Message-ID: <yYCsj.7867$%q3.7334_at_trndny07>


"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:aQCsj.8653$0w.3454_at_newssvr27.news.prodigy.net...
>
> "David Cressey" <cressey73_at_verizon.net> wrote in message
> news: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.
> >
>
> It's much quicker to use a binary search algorithm to find malfunctions.
> (That's what I did when I was in the military.) It takes a lot less time
to
> probe 5 points than 30. Of course explaining that to someone who's always
> worked backward is a challenge--especially if it's your supervisor.
>

You missed the major point. Received on Wed Feb 13 2008 - 15:15:58 CET

Original text of this message