Re: OO versus RDB

From: H. S. Lahman <h.lahman_at_verizon.net>
Date: Tue, 27 Jun 2006 14:36:01 GMT
Message-ID: <lnbog.14947$pv2.12108_at_trndny05>


Responding to mAsterdam...

>>>>>>> In retrospect I think that what we were doing was trying to
>>>>>>> reach for (never to achieve) the level of data-independence
>>>>>>> which is now achievable with SQL-DBMS's even if they aren't up
>>>>>>> to RM-purist's standards. But, as I said, I will pay attention,
>>>>>>> maybe there are even more benefits to a layered approach of data.
>>>>>>
>>>>>>
>>>>>> I would suggest even further isolation.
>>>>>
>>>>>
>>>>> Because this benefits ... what?
>>>>
>>>>
>>>> Separation of concerns.
>>>
>>>
>>> Worthwhile. Which concerns? Code and data organization.

>>
>>
>> No.  Problem solutions vs. persistence.
> 
> 
> You snipped:
> 

>>> ISTM persistence is no issue. A few weeks
>>> ago I asked cdt & co for a relevant definition.
>>> Maybe you have one.
> 
> 
> Why?

I didn't know what the first sentence meant and I didn't know who "cdt & co" was.

> 
> [snip]
> 
>> 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.

> 

>>>>>> So one should hide the SQL as well.
>>>>>
>>>>>
>>>>> As soon as we have a better embeddable
>>>>> abstraction, yes. Please provide an url.
>>>>
>>>>
> [snip OODB & flatfile]
> 

>>>> Or you change RDB vendors?
>>>
>>>
>>> Then you have to change the vendor specifics in the code and migrate
>>> the data.
>>
>>
>> The point is that the application problem solution does not care how 
>> the data is stored. Nor should it be affected by any changes to the 
>> data storage that do not effect its semantics. 
> 
> 
> We are in agreement here.
> 
> Were we differ is:
> You (appear to) assume that dbms and SQL are about storage.
> I don't.

I believe they are about managing stored data.

>>>> As such, it should be hidden from the rest of the application that
>>>> doesn't care what flavor of persistence is used.
>>>
>>>
>>> In the case of using SQL as interface to users data:
>>> make sure that only that part of our code which
>>> processes some specific data mentions only that
>>> part of the schema which is relevant to it.

>>
>>
>> Better yet, encapsulate it so that none of the  problem solution code 
>> mentions it.
> 
> 
> Hiding irrelevant stuff seems sensible.
> Not mentioning the relevant stuff seems a bit weird.
> 
> Metaphorically:
> I can imagine some transport layer being
> ignorant of the content of the luggage.

Conversely, some baggage content layer could be ignorant of transport mechanisms.

>>> I don't see how an extra layer dealing
>>> with (especially when specific data) could help
>>> - ISTM it only blurs the separation of concerns.

>>
>>
>> Encapsulation and isolation.  When the schemas and/or access paradigms 
>> change one does not have to touch the problem solution in any way.  So 
>> one can be confident that the problem solution still works.  All one 
>> needs to validate is that the layer or subsystem interface still 
>> provides the same data in response to requests from the problem solution.
> 
> 
> A schema change breaks a query or it doesn't.
> If it doesn't all is well.
> If it does you'll have to investigate the code
> dependent on the query.

It breaks the query, but not the problem solution that needs the data. The change is isolated to modifying the query. If that query construction is isolated from the problem solution then the problem solution is unaffected. If the query construction is embedded in the problem solution, then there is always some chance the solution will be broken.

> 
> [snip]
> 

>>>>> SQL DBMS mostly use files in file systems for storage.
>>>>> Why place SQL DBMS in between if you are just looking for storage?
>>>>
>>>>
>>>> Because outside the realm of CRUD/USER the problem solution should
>>>> not depend upon the persistence mechanisms.
>>>
>>>
>>> No - I'll rephrase: why not use storage systems for storage?
>>> Why use SQL as a go-between at all?
>>
>>
>> I don't care what storage paradigm is used or what access mechanisms 
>> one uses to access the data store.  The point is that, whatever they 
>> are, they should be isolated from the problem solution so that they 
>> are completely transparent to the problem solution.
> 
> 
> 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?

That's pretty much my point. You can use whatever mechanisms you want for storage management if they are isolated from the application problem solution.



There is nothing wrong with me that could not be cured by a capful of Drano.

H. S. Lahman
hsl_at_pathfindermda.com
Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH Received on Tue Jun 27 2006 - 16:36:01 CEST

Original text of this message