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

Content-Type: multipart/alternative;
 boundary="------------E0AB581822A8B742068C2596"

--------------E0AB581822A8B742068C2596
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

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?

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

Again, you've lost me. There are those who tightly couple procedural and relational as a style of programming. But you denigrate "procedural ... access"

> > > > 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. Each and every object can be stored anywhere (isn't this a super set of breaking the base table vertically AND horizontally). You complain about object databases using physical pointers to "improve joins".

> > 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 physical does NOT mirror the logical, there is necessarily an indirection step to provide this illusion.

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

> > > 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. I still can't see your point here.

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

Other "communities" have shied away from ANY dbms because the "big market" products could not meet their needs. Some of these users have found the ability to represent complex data with high performance using current object databases.

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. I see today's object databases as something new.

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

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

--------------E0AB581822A8B742068C2596
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
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.
<p>These competing views have proven nearly impossible to reconcile in
this thread.
<p>Bob Badour wrote:
<blockquote TYPE=CITE>"Jim Melton" &lt;Jim.Melton_at_Technologist.com> wrote
in message
<br><a href="news:3BB7F36D.4E5D00F0_at_Technologist.com">news:3BB7F36D.4E5D00F0_at_Technologist.com</a>...
<br>> What are the fundamental features of a language "raised" to the level
of the
<br>> DBMS?
<p>The ability to describe operations at the level of intent or closer
to the
<br>level of intent. The language would have to understand relation types,
<br>relation variables, relation values, relational algebra etc.</blockquote>

<p><br>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".
<p>C = A + B
<p>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?
<br>&nbsp;
<blockquote TYPE=CITE>> How are "non-relational object databases" lowering
the DBMS to the level of the
<br>> (existing) programming language?
<p>By forcing procedural, navigational access methods with no physical
<br>independence.</blockquote>

<p><br>Again, you've lost me. There are those who tightly couple procedural
and relational as a style of programming. But you denigrate "procedural
... access"
<br>&nbsp;
<blockquote TYPE=CITE>> > > This *is* the domain
<br>> > > of todays object databases although it has little to do with
the underlying
<br>> >
<br>> > > storage system.
<br>> >
<br>> > I disagree. The domain of today's (non-relational) object databases
is
<br>> > ignorance and desperation. It has everything to do with the underlying
<br>> > storage system and with the failure of SQL dbms vendors to provide
adequate
<br>> > physical independence.
<br>>
<br>> The heart of your arguments in the past seem to have been centered
on the
<br>> notion of physical independence promised by the relational *model*.
Why do you
<br>> suppose SQL dbms vendors have failed to provide it?
<p>They have provided some, but entirely inadequate, physical independence.
For
<br>instance, several SQL products allow data clustering, and all SQL products
<br>allow some rudimentary indexing. I am not aware of any SQL product
that
<br>allows one to break up a base table vertically into multiple storage
areas,
<br>and precious few allow one to break up a table horizontally for storage.
I
<br>am not aware of any SQL product that will index partial aggregates.
I am not
<br>aware of any SQL product that uses physical pointers or pointer pools
among
<br>tables to improve joins; although, surely there must be at least one.</blockquote>

<p><br>Hmmm. My object database allows data clustering and rudimentary
indexing. Each and every object can be stored anywhere (isn't this a super
set of breaking the base table vertically AND horizontally). You complain
about object databases using physical pointers to "improve joins".
<br>&nbsp;
<blockquote TYPE=CITE>> Could it be that every
<br>> level of indirection incurs a performance penalty and they cannot
build
<br>> performant systems with complete independence?
<p>Independence does not require indirection.</blockquote>

<p><br>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 physical does NOT mirror the logical, there is necessarily an indirection
step to provide this illusion.
<br>&nbsp;
<blockquote TYPE=CITE>> If it is fundamental to the relatioal model, is
it possible that your
<br>> relational model cannot be implemented in a commercially viable product?
<p>It is possible. Nobody has really attempted it, though. As long as users
<br>demand physical dependence as a "solution" for performance, I doubt
that
<br>anyone will.</blockquote>

<p><br>If an equally performant independent solution is possible, why wouldn't
users prefer it? You seem a little lost in your ivory tower here.
<br>&nbsp;
<blockquote TYPE=CITE>> > Ultimately, the most performant middleware is
written by the DBMS vendor,
<br>> > but this is not necessarily the best or most needed middleware.
<br>>
<br>> Care to elaborate? What would you see as the "best or most needed
middleware"?
<p>Any middleware not written by a vendor is written by whom? The user
<br>community. If the user community undertakes to write additional middleware,
<br>one can easily assume that it better meets the needs of users.</blockquote>

<p><br>If I write it, it's an application. It's middleware if I buy it
from a vendor. I still can't see your point here.
<br>&nbsp;
<blockquote TYPE=CITE>> Technical superiority (note we're still debating
that) has little to do with
<br>> market dominance. My proof?
<br>>
<br>> Microsoft.
<p>I agree. For additional proof, SQL won and Quel lost.
<p>However, network model databases have proved their inferiority in the
market
<br>as well. One need only look at the recent history of Informix to see
how
<br>much the dbms community demands navigational access. Some of the
<br>non-relational object dbms products have been on the market for over
a
<br>decade without making significant market penetration. At one time,
IMS owned
<br>the database management market. While I am sure that many large companies
<br>still use it, what fraction of the total database market do you suppose
it
<br>has today?</blockquote>

<p><br>I don't think there is a monolithic "dbms community". 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.
<p>Other "communities" have shied away from ANY dbms because the "big market"
products could not meet their needs. Some of these users have found the
ability to represent complex data with high performance using current object
databases.
<p>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. I see today's object databases as something
new.
<p>I don't really care about the size of the database market. As I said
previously, market dominance just shows effective marketing.
<p><tt>--</tt>
<br><tt>Jim Melton, novice guru&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| So far as we know, our</tt>
<br><tt>e-mail: Jim.Melton_at_Technologist.com | computer has never had</tt>
<br><tt>v-mail: (303) 971-3846&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| an undetected error.</tt></html>

--------------E0AB581822A8B742068C2596--

--------------C20A719B923920A4A2656A5B
Content-Type: text/x-vcard; charset=us-ascii;
 name="Jim.Melton.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jim Melton
Content-Disposition: attachment;
 filename="Jim.Melton.vcf"

begin:vcard 
n:Melton;Jim
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:Jim.Melton_at_Technologist.com
x-mozilla-cpt:;1
fn:Jim Melton
end:vcard

--------------C20A719B923920A4A2656A5B--