Re: OO versus RDB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 25 Jun 2006 20:05:09 +0200
Message-ID: <449ecfdd$0$31642$e4fe514c@news.xs4all.nl>

H. S. Lahman wrote:
> 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?

[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?

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

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

Paradigms? To big a word IMO.

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

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

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

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

Received on Sun Jun 25 2006 - 13:05:09 CDT