Re: OO versus RDB

From: mAsterdam <>
Date: Sun, 25 Jun 2006 01:54:50 +0200
Message-ID: <449dd059$0$31656$>

  • restored xpost to cdt * 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.

> 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 Sun Jun 25 2006 - 01:54:50 CEST

Original text of this message