Re: Mixing OO and DB

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 13 Feb 2008 10:46:42 -0400
Message-ID: <47b302d9$0$4042$9a566e8b_at_news.aliant.net>


David Cressey wrote:

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

And he ignored the potential for fan-in/fan-out. Received on Wed Feb 13 2008 - 15:46:42 CET

Original text of this message