Re: OO versus RDB

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

<snip paradigm vagueness>

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

So?

> The benefits are the same benefits one
> gets from any software modularization:
> simplifying subject matters; containment, reuse, and -- most relevant
> for this thread -- context-independence.

, in casu database independence, at the cost of 1. if you have dbms: a lesser facade with roll-your-own abstractions. 2. if you haven't: a roll-your-own dbms, and in both cases modules still fully dependent on the relevant part of the conceptual schema (whether it is coded or not, the latter being the toughest spot to be in).

Not really a hard decision.

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

> I was qualifying by example because of your difficulty
> with common terms like 'problem solving'.

YMMV as to what are common terms.
That I do not accept your narrow usage of the term does not mean I have difficulties with the term 'problem solving'. I have no difficulty with the term 'problem solving'. I do not accept your narrow usage of the term. I also do not accept your sloppy usage of the term paradigm.

>>>>>>> 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 don't follow this at all. 
>>
>> mm.: mutatis mutandis. Just try to fill it in.

What part of
 >>>> I won't bother.
didn't you believe?

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

As far as I can see, you mean this to include the relevant part of the schema.

Right?

IMO it won't go that far.

>>>>>>>>>> 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.
>>>
>>> OK, then I don't understand what your point is.
>>
>> What did Bill buy the DBMS for. Is he stupid?

He bought it as a tool for data management. Skip the storage, he still has to buy that. Bill also still needs to design and build, or buy a schema for his data.

> Most commercial DBMSes today
> employ a paradigm that implements the RDM with RDBs.

Aaargh! The P-word!

> However, Bill also buys or builds software applications to solve
> particular business problems and those software applications will get
> their data from the DBMS because that is what Bill provided. But the
> solutions to those problems don't depend in any way on the particular
> storage and access mechanisms in Bill's DBMS; they just need the data
> and they want an interface to it that is tailored to their needs rather
> than the specific storage and access mechanisms.

The schema hides storage and physical access mechanisms from the applications, and provides logical access. I get the impression that the purpose of the layer you want to construct on top of a DBMS (or none) is in fact the purpose of the schema.
Picturing the DBMS in the storage realm makes room for your "context-independence" layer.

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