Re: OO versus RDB
Date: Tue, 27 Jun 2006 23:45:56 +0200
Message-ID: <44a1a679$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?
>
> I didn't know what the first sentence meant
> and I didn't know who "cdt & co" was.
I guess you know by now:
ISTM: It seems to me (YCLIU)
cdt & co: the newsgroups comp.databases.theory and comp.object
>> [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.
"form of"? "problem solving" (in general instead of
some category of problems) - I all sounds huge, but
I fail to see what you mean by it.
OO is one set of solutions for one problem,
I'll try something I could understand using similar words:
Data management is done by people.
A DBMS is part of the toolkit.
>>>>>>> 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.
and, off-hand,
- providing suitable abstractions for programs to manipulate those 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.
Sure. But how is this relevant to hiding the *relevant* stuff?
>>>> 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.
Is your "problem solution" synonymous to "the code"? If not what do you mean.
> 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?
Indeed it is not.
> 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.
Code, isolated from relevant data is irrelevant to the application. This is a good thing for e.g. transport layer code and generic parts of user-interfaces used by other applications. (These do have their own data, relevant to them, BTW).
Maybe you have been exposed to very much
very bad code ("problem solution") in this respect.
Code by designers/programmers who say:
give me all data, I'll sort out what I need myself
(in my code) later.
-- "The person who says it cannot be done should not interrupt the person doing it." Chinese Proverb.Received on Tue Jun 27 2006 - 23:45:56 CEST