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

In article <iR4y7.3025$YW6.96544881_at_radon.golden.net>,  "Bob Badour" <bbadour_at_golden.net> wrote:

> "Jim Melton" <Jim.Melton_at_Technologist.com> wrote in message
> > > > 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.

[...]

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

You are just arguing for abstraction and encapsulation. Somewhere the definition of how a sum of values is calculated (and derivative statistics such as mean, std deviation, variance, etc.) must be defined. If it is defined as an operation in your database, then one common operation can be invoked by all users of the database.

Of course, the user who never needs to compute the variance of a series of numbers pays for a feature he does not need. Therefore, the set of features included is market driven and not theory-based.

Or would you expect a programming language in which one might (out of the box) write "P(snow in Anchorage tommorow|weather database)" [the probability of snow in Anchorage tommorow given the contents of the weather database]

I can't see that as a "feature" of a language.

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

So your point would be that since my object database provides these features and the SQL databases do not, then it is not inherent in ANY logical data model?

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

Well, since you've stated repeatedly that an object maps to a domain which is a column of a table, I'll say that any object value (domain value) can be stored in any one storage area. I hope you weren't suggesting splitting individual cells across storage areas. That would be a little hard to swallow. No object is stored in multiple storage areas (data replication aside). Reference the previous discussion about where objects "live".

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

Invective does nothing to improve your position. The "pointers" in an object database merely pre-store the results of joins that will be required later. There is an immense performance benefit.

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

Pre-compiled queries are usually called stored procedures. I didn't think you liked them.

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

Regardless of what I say. Indirection or transformation is required. If in some way you can precompute and store this transformation, haven't you just changed your physical implementation to match your logical one (or vice versa, I'm not sure).

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

You seem to hold a mighty low view of me and my fellow practitioners.

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

Can't. The DBMS vendor doesn't (necessarily) write the best or most needed middleware. The user community will write this, where the user community is defined (non-exclusively) as the open-source initiatives.

Huh?

In my organization, we always have make/buy decisions. In almost every case, if I can buy it, it is more cost-effective than if I make it. If I make it, then I accept the life-cycle and maintenance costs associated. A commercial product can spread these costs across all of its customers and achieve much greater economies of scale.

Open-source is included in make/buy decisions, but the uncertainty of support is usually a non-starter for our customers (in essence, we commit to the support costs).

If your vendors don't listen to you and provide you the features you require, get a different vendor (didn't you already make a point very much like this?).

> > I don't think there is a monolithic "dbms community".
>
> Who do you suppose reads comp.databases and comp.databases.theory ?

I don't know. I read comp.databases.object. Are we not part of the "dbms 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?

From what I've learned of relational theory over this thread, if such a database existed (that had native programming language support for objects and was fully relational and physically independent and at least as performant as my current solution), I would be interested.

But yes, they lack choice of a theoretically pure relational database.

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

OK. If that's true (can't/won't argue it, since I'm not versed in 30-year-old database technology), then it's enough for me and some number of other users, for now.

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

Sure.

"In theory there is no difference between theory and practice, but in practice there ususally is."

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