Re: OO versus RDB

From: H. S. Lahman <h.lahman_at_verizon.net>
Date: Sun, 25 Jun 2006 14:45:18 GMT
Message-ID: <2kxng.7938$Wl.4566_at_trnddc01>


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.

>>>> The application solution doesn't care if the data is in an RDB, an 
>>>> OODB, flat files, or clay tablets.  
>>>
>>>
>>> Well, the user does care about his data.
>>> That's why he put them on clay tablets
>>> (or one of the other) to begin with.
>>> What type of user-beneficial application solution
>>> should not care about where the user's data is?
>>
>>
>> The user doesn't care where the data is either.  Nor does the user 
>> have any direct access to the data; it is all through software.  The 
>> customer just decides What needs to be persisted, not how it is 
>> persisted. Persistence is a Systems Engineering decision.

>
>
> This is about persisted objects (bits & bytes to the user),
> not about data as in meaningful, user visible data - the
> stuff data-management and databases are about.
> Now I know some would call that information instead of data, but that
> would mean we'd have to talk about
> information-bases and limping stuff like that.

No, it is about solving problems (OO) vs. persisting data (data management).

>

>>>> So one should hide the SQL as well.
>>>
>>>
>>> As soon as we have a better embeddable
>>> abstraction, yes. Please provide an url.
>>
>>
>> What if you decide an OODB would be better?

>
>
> If a problem at hand doesn't need
> data-management, I might recommend one if
> say a software vendor has build a
> niche-solution needing it.
>
>> Or flat files?    

>
>
> If a flat file will do it will do.
> No need to spend more.
>
>> 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. In half a century in this business I've observed the introduction of five major paradigms for persistence. I would not bet against yet another appearing.

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

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

>> One provides that encapsulation with a subsystem interface that is 
>> tailored to the problem solution's needs.  Ideally one employs a pure 
>> message interface: {message ID, data packet}.  It is then the 
>> persistence access subsystem's job to map that message into a SQL 
>> query or whatever else is needed.
>>
>>>> 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.
>>>
>>>
>>> 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.



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 Sun Jun 25 2006 - 16:45:18 CEST

Original text of this message