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

"Jim Melton" <Jim.Melton_at_Technologist.com> wrote in message news:3BC3C2ED.BCC2D26_at_Technologist.com...
> Another poster to this thread pointed out that comp.databases.theory is a
group
> concerned largely with the way things ought to be. On the other hand,
> comp.databases.object tends to be more concerned with how things are,
> specifically as relates to object databases. I don't know what the focus
of
> comp.databases is.
>
> These competing views have proven nearly impossible to reconcile in this
> thread.
>
> Bob Badour wrote:
>
> > "Jim Melton" <Jim.Melton_at_Technologist.com> wrote in message
> > news:3BB7F36D.4E5D00F0_at_Technologist.com...
> > > 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.
>
> I'm sure it's no surprise to you, but this doesn't communicate to me. I've
> never used a programming language that did not describe operations at the
> "level of intent".
>
> C = A + B
>
> says assign to C the additive combination of A and B (note that no types
are
> inherent in this expression, providing great expressive power in a variety
of
> different contexts). How does that not express intent?

In the extremely simple example given, one expresses intent using C = A + B. However, if C = A + B is only one step in a loop that calculates the standard deviation or a sum of values in a relation (array or whatever), then it does not express the level of intent.

> > > > > 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.
>
> Hmmm. My object database allows data clustering and rudimentary indexing.

The question is: How is this inherent to the logical data model used?

> Each
> and every object can be stored anywhere (isn't this a super set of
breaking the
> base table vertically AND horizontally).

Really? Can I tell your odbms that I want to store some of the simple attributes of an object in one storage area, that I want to store some of the simple attributes in a different storage area and that I want to store some of the simple attributes in both?

> You complain about object databases
> using physical pointers to "improve joins".

I have never made any such complaint or any such claim. Non-relational object databases expose physical pointers in the logical model out of ignorance and without any benefit at all.

> > > 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.
>
> That will take some substantiation. If there is no indirection (or
translation,
> which is essentially the same thing), then the logical must be identical
to the
> physical, and you've argued vociferously against that. If the

I disagree. Independence neither requires nor prohibits any level of indirection. During execution, no translation is required because all translation can occur in advance allowing the DBMS to use a statically compiled access path.

> physical does NOT
> mirror the logical, there is necessarily an indirection step to provide
this
> illusion.

If you say so.

> > > 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.
>
> If an equally performant independent solution is possible, why wouldn't
users
> prefer it? You seem a little lost in your ivory tower here.

Control and perception. Even if such a solution existed, users would have to perceive the benefit. Very few programmers would perceive the benefit, and all programmers would perceive a loss of personal control.

Some people would prefer to treat snakebite at the local swami, guru or shaman even when anti-venom is available. Sometimes such preferred treatments even work (when the snake was not poisonous.) In the marketplace, perception is more important than results -- at least in the short-term.

> > > > 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.
>
> If I write it, it's an application. It's middleware if I buy it from a
vendor.

Not necessarily. If you write it as part of an open-source initiative, it's middleware. If you write it for other programming groups in your organization, it's middleware. If your application is middleware, it's both.

> I still can't see your point here.

Can't or won't?

> > > 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?
>
> I don't think there is a monolithic "dbms community".

Who do you suppose reads comp.databases and comp.databases.theory ?

> There is certainly a
> large market for repeated queries over relatively static, well structured
data
> (sales invoices, employee records, etc.). For this "community", a
relational
> database is adequate if not ideal.

An SQL database will suffice for this "community".

> Other "communities" have shied away from ANY dbms because the "big market"
> products could not meet their needs.

Because products fail to implement the relational model.

> Some of these users have found the ability
> to represent complex data with high performance using current object
databases.

If no other tools with adequate domain support exist, these users lack choice, do they not?

> I know you see current object databases as nothing different than the
network
> databases of 30 years ago, but I couldn't do the things I'm doing with
> 30-year-old technology.

There is a difference between current network model databases and the network model databases of 30 years ago. The current network model databases have better domain support.

> I see today's object databases as something new.

New compared to what, though? Compared to other network model databases that lack adequate domain support? Compared to the relational model that already required support for domains back in 1970? Compared to SQL databases that simply chose not to support domains?

> I don't really care about the size of the database market. As I said
> previously, market dominance just shows effective marketing.

I agreed then, and I agree now. Received on Sun Oct 14 2001 - 02:18:03 CEST