Re: OO versus RDB
Date: Sun, 25 Jun 2006 01:54:50 +0200
Message-ID: <449dd059$0$31656$e4fe514c_at_news.xs4all.nl>
- 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.
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