Re: Clean Object Class Design -- What is it?

"Jim Melton" <Jim.Melton_at_Technologist.com> wrote in message news:3BB7F36D.4E5D00F0_at_Technologist.com...
>
>
> Bob Badour wrote:
>
> > "Carl Rosenberger" <carl_at_db4o.com> wrote in message
> > news:9njddh$gl2$01$1_at_news.t-online.com...
> > > A very tight binding to programming languages can make products
superior
> > for
> > > certain usecases, since mechanisms need less overhead.
> >
> > I am not against a programming language that is tightly bound to the
DBMS --
> > I think such a product has great potential merit. However, I suggest
that
> > improving the programming language and raising it to the level of the
DBMS
> > surpasses regressing the DBMS and lowering it to the level of an
existing
> > programming language.
>
> What are the fundamental features of a language "raised" to the level of
the
> DBMS?
The ability to describe operations at the level of intent or closer to the level of intent. The language would have to understand relation types, relation variables, relation values, relational algebra etc.

> How are "non-relational object databases" lowering the DBMS to the level
of the
> (existing) programming language?

By forcing procedural, navigational access methods with no physical independence.

> > > This *is* the domain
> > > of todays object databases although it has little to do with the
underlying
> >
> > > storage system.
> >
> > I disagree. The domain of today's (non-relational) object databases is
> > ignorance and desperation. It has everything to do with the underlying
> > storage system and with the failure of SQL dbms vendors to provide
adequate
> > physical independence.
>
> The heart of your arguments in the past seem to have been centered on the
> notion of physical independence promised by the relational *model*. Why do
you
> suppose SQL dbms vendors have failed to provide it?

They have provided some, but entirely inadequate, physical independence. For instance, several SQL products allow data clustering, and all SQL products allow some rudimentary indexing. I am not aware of any SQL product that allows one to break up a base table vertically into multiple storage areas, and precious few allow one to break up a table horizontally for storage. I am not aware of any SQL product that will index partial aggregates. I am not aware of any SQL product that uses physical pointers or pointer pools among tables to improve joins; although, surely there must be at least one.

> Could it be that every
> level of indirection incurs a performance penalty and they cannot build
> performant systems with complete independence?

Independence does not require indirection.

> If it is fundamental to the relatioal model, is it possible that your
> relational model cannot be implemented in a commercially viable product?

It is possible. Nobody has really attempted it, though. As long as users demand physical dependence as a "solution" for performance, I doubt that anyone will.

> > > A tight language binding could very well also be part of a
> > > relational database. You called it "middleware" in a thread some time
ago,
> > > but the more a vendor implements himself, the more efficient a system
is
> > > bound to be.
> >
> > Ultimately, the most performant middleware is written by the DBMS
vendor,
> > but this is not necessarily the best or most needed middleware.
>
> Care to elaborate? What would you see as the "best or most needed
middleware"?

Any middleware not written by a vendor is written by whom? The user community. If the user community undertakes to write additional middleware, one can easily assume that it better meets the needs of users.

> > > Some 200 postings ago I mentioned that relational databases and object
> > > databases will converge. Your posting suggests that you see a chance
also.
> >
> > Some 200 postings ago, I mentioned that relational databases already are
> > object databases and need no convergence. The non-relational products,
such
> > as your product, have a dim future.
>
> Technical superiority (note we're still debating that) has little to do
with
> market dominance. My proof?
>
> Microsoft.

I agree. For additional proof, SQL won and Quel lost.

However, network model databases have proved their inferiority in the market as well. One need only look at the recent history of Informix to see how much the dbms community demands navigational access. Some of the non-relational object dbms products have been on the market for over a decade without making significant market penetration. At one time, IMS owned the database management market. While I am sure that many large companies still use it, what fraction of the total database market do you suppose it has today?

>
> --
> Jim Melton, novice guru | So far as we know, our
> e-mail: Jim.Melton_at_Technologist.com | computer has never had
> v-mail: (303) 971-3846 | an undetected error.
>
Received on Sat Oct 06 2001 - 17:21:44 CEST