Re: OO versus RDB

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

Data storage is one of *many* features of a DBMS. If mere storage is all that is needed, then one could use files. DBMS roll up a bunch of common attribute management services and needs into a semi-standardized package so that you don't have to reinvent lots of wheels, and have a consistent way to view, edit, and process attributes. It is factoring; reuse of common attribute idioms. (Unlike OO, where encapsulation encourages each object/class to reinvent its own add/change/delete/cross-reference/search rules and interfaces so that they are all different for each project or shop. That is not factoring of repetitious ideas, but an encouragement of reinvention, inconsistency, and duplication.)

You don't have to use all the services a DBMS supply. In fact, you could use it as merely a filing system. However, that does not mean that DBMS *are* just filing systems.

Saying a RDBMS is about "storage" is almost like saying the purpose of a car is to store gas.

A database is an "attribute management system". OOP can and often is also an attribute management system, just a lousy, inconsistent one.

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

Only if you use a lowest-common-denominator interface. I would challenge the power of such an interface with scenarios and probably kick its rear end all over the floor with a RDBMS. Concurrency management alone would probably sink it.

So, let's see your generic "storage" API/wrapper.

>
> H. S. Lahman

-T- Received on Tue Jun 27 2006 - 21:56:04 CEST