Re: Mixing OO and DB

From: Brian Selzer <brian_at_selzer-software.com>
Date: Wed, 13 Feb 2008 14:07:02 GMT
Message-ID: <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.

> 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 - 15:07:02 CET

Original text of this message