Re: OO versus RDB
Date: Sun, 25 Jun 2006 20:05:09 +0200
Message-ID: <449ecfdd$0$31642$e4fe514c_at_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 - 20:05:09 CEST