Re: OO versus RDB

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

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

Good.

> CRUD/USER processing is still an
> enormous part of IT software and the RM-based RAD IDEs have that pretty
> well in hand. Similarly, functional programming represents the best
> approach I know of to algorithmic processing when requirements are
> nonvolatile. There are a number of other, more specific problem spaces
> where OO techniques are not the best choice.
>

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

Yes. It comes with the word paradigm.
Using simpler words may help to stay on topic.

> I also don't understand why you keep bringing up OO development; it is
> completely OT. The context here is about application partitioning where
> one isolates knowledge about data storage and access mechanisms away
> from the problem solution logic within an application. That is basic
> separation of concerns and modularization that one does whether the
> application is constructed with OO techniques or not.

Earlier in this thread you said:

  > I would suggest even further isolation.  The application solution
  > doesn't care if the data is in an RDB, an OODB, flat files, or clay
  > tablets.  So one should hide the SQL as well.
  >
  > In so doing one can often provide reusable storage access across
  > applications where one only needs to provide a subsystem interface
  > and identity mapping to access the data for a particular context.
  > SQL is particularly suited to this because one is just concatenating
  > identity strings.

and I asked you to point out the benefits of that approach. It seems I have to accept a - to me - wrong look at the role of schemata and databases to see those benefits.

[snip]

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

Earlier in this thread you said:
  > No, it is about solving problems (OO) vs. persisting data (data management).

> This list was in response to your questioning what "problem solving" is.

I was trying to find out about your strange, narrow usage of the term in the above sentence.

> These are examples of the appropriate level of abstraction for defining
> problems for individual software applications.
>

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

mm.: mutatis mutandis. Just try to fill it in.

> OO is one of many techniques for
> constructing software applications. Applications are constructed to
> solve specific business problems. The issue is what applications do
> relative to what DBMSes do, not what OO does.

I think your issue was (because of
"When the schemas and/or access paradigms change one does not have to touch the problem solution in any way." ) that hiding the data from the application isn't only possible, it is something to actually aim for. It isn't possible. In order to see that, the role of the schema should be explored.

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

What did Bill buy the DBMS for. Is he stupid?

In a typical 'get up to speed quickly' book on some programming language the DBMS is pictured as a storage engine, to be able to focus on the language features. This is an "educational shortcut" (scarequotes indicating I don't agree) which is hard to get away from later. In order to understand what the role is really ask yourself the question:

What did Bill buy the DBMS for. Is he stupid?

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