Re: OO versus RDB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 29 Jun 2006 20:51:37 +0200
Message-ID: <44a42097$0$31656$e4fe514c@news.xs4all.nl>

H. S. Lahman wrote:
> Responding to mAsterdam...

[snip persistence]

>>>>>>> ... No, it is about solving problems (OO) 
>>>>>>> vs. persisting data (data management).
>>>>>>
>>>>>> What do you mean with "solving problems (OO)" -
>>>>>> are they synonyms to you?
>>>>>
>>>>> No.  OO is one form of problem solving just as 
>>>>> a RDB-based DBMS is one form of data management.
>>>>
>>>> "form of"? "problem solving" (in general instead of
>>>> some category of problems) - I all sounds huge, but
>>>> I fail to see what you mean by it.
>>>> I'll try something I could understand using similar words:
>>>>
>>>> OO is one set of solutions for one problem,
>>>> how to organize code: 'Sesame, open!' instead of 'Open Sesame!'.
>>>
>>> I prefer: OO is a paradigm for solving problems on a computer.  
>>
>> Big words ('paradigm', 'solving problems') only
>> confuse the issues.

>
> They have well-established definitions (e.g., a paradigm is a conceptual
> model) so they enhance communication.

http://en.wikipedia.org/wiki/Paradigm supports you, but also gives:
'Some language purists feel that among "business philosophers" and advocates of any type of change whatsoever, the term paradigm is widely abused and in that context bears no meaning whatsoever.'

I don't think I am a language purist, but I share that opinion. Now if we would be discussing paradigmatic behaviour: Why some OO adepts refuse to discuss other problem-solving at all, or why some RM adepts refuse to admit that order may have meaning, I'd accept paradigm as a useful concept. See also:

http://groups.google.nl/group/comp.databases.theory/browse_frm/thread/3e9cff0677ec34c1/03b78f4ae032a74e?lnk=st&q=(paradigmatic)+group%3Acomp.databases.theory+author%3AmAsterdam&rnum=4&hl=nl#03b78f4ae032a74e

...I suspect a lot of the miscommunication between people from different schools of thought is due to stretching the meaning of school-internal words when confronted with problematic issues, partly to avoid the use of *their* concepts, partly to cover up paradigmatic blind spots. Not unlike the not-invented-here syndrome.

Three examples would be

Orthogonal persistence in the object school to dissmiss all problems of data sharing as 'implementation issues'.
Stretching *type* in the relational school to dismiss 'class' as a valid concept and still have it.
(Most unfortunate:) stretching *meaning* to include *use*.

>> What problem does one attempt to solve with
>> OO but the organization of code?

>
> That's true,

Good.

> but so abstract it is irrelevant for this context.

If you mean this (our) discussion with "this context" I veto that.

> General Ledger. Inventory control.
> Printer device driver. ad infinitum. Every
> computer application solves a specific problem for some customer.

None of these is OO specific.

>>> However, my objection above was that it is not synonymous with 
>>> problem solving because problems can be solved on a computer with 
>>> different paradigms than OO.
>>>
>>>> Data management is done by people.
>>>> A DBMS is part of the toolkit.
>>>
>>> Fine.  Just as problems are solved by people while editors, 
>>> compilers, code generators, etc. are tools.
>>>
>>> The point is that data management and problem solving are quite 
>>> different concerns and activities.
>>
>> ?? Data management does not solve problems? Are you sure?

>
> It solves problems that are restricted to that realm, such as ensuring
> data integrity. In a broad sense it can include notions like data
> warehousing but in this context I see it as being about the services
> that a DBMS provides. It generally does not involve solving specific
> business problems.

Why do you only state this for DBMS , it goes mm. for OO as well. I won't bother.

[snip]

>>> I really don't know why this notion of separation of concerns is such 
>>> a novelty.  
>>
>> Your assumption is wrong.

>
> What assumption?

[snip]

>>>>>> I don't use paradigms for storage.
>>>>>> I don't use a dbms for storage.
>>>>>
>>>>> Codd's relational data model as implemented in RDBs is not a data 
>>>>> storage paradigm?
>>>>
>>>> Indeed it is not.
>>>
>>> Wow.  I give up.  This disagreement is so profound I don't even know 
>>> how to begin to respond.
>>
>> What is there to disagree on?
>>
>> Assume Bill wants storage.
>> Say he goes to the shop and buys a DBMS.
>> Now Bill still needs to buy storage!?
>> What did he buy the DBMS for?

>
> I don't understand this. You seem to be equating data storage to
> hardware. The hardware platform is not relevant.

Your assumption here is also wrong.

-- 
"The person who says it cannot be done
should not interrupt the person doing it."
Chinese Proverb.

Received on Thu Jun 29 2006 - 13:51:37 CDT