Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: OO versus RDB

Re: OO versus RDB

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 25 Jun 2006 01:54:50 +0200
Message-ID: <449dd059$0$31656$e4fe514c@news.xs4all.nl>

Worthwhile. Which concerns? Code and data organization.

> The problem solution is not dependent upon
> persistence mechanisms.

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

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

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

> However, that isn't the point. SQL is an implementation
> mechanism for a particular form of persistence.

Using SQL for persistence is like using money for toilet-paper. It works, but it doesn't feel good.

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

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

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

-- 
"The person who says it cannot be done
should not interrupt the person doing it."
Chinese Proverb.
Received on Sat Jun 24 2006 - 18:54:50 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US