Re: OO versus RDB

From: mAsterdam <>
Date: Thu, 29 Jun 2006 20:51:37 +0200
Message-ID: <44a42097$0$31656$>

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

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

  1. Orthogonal persistence in the object school to dissmiss all problems of data sharing as 'implementation issues'.
  2. Stretching *type* in the relational school to dismiss 'class' as a valid concept and still have it.
  3. (Most unfortunate:) stretching *meaning* to include *use*.
>> What problem does one attempt to solve with
>> OO but the organization of code?

> That's true,


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


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

> What assumption?


>>>>>> 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 - 20:51:37 CEST

Original text of this message