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

>>Why should vendors provide support for declarative integrity constraints
>>when they can fool customers into thinking that triggers and stored
>>procedures solve the problem?
>
>Do you really know all the performance, concurrency and other problems of
>implementing, say, subqueries in check constraints?

I have a pretty good idea, and I have a pretty good idea why SQL, in particular, has difficulties -- allowed duplicates, NULL, language redundancies etc.

I suppose your solution is to not check any constraints?

>>Why should relational DBMS vendors provide adequate support for domains
 when
>>the markets that demand them most scoff at the idea of using a relational
>>database?
>
>Is implementing user defined domains straightforward?

I don't know. Is implementing user defined object classes straightforward?

>Why then relational
>vendors come up with cludgy object/relational implementations instaed of
 just
>implemnting java type based domains?

Why would you limit the DBMS to Java? Why would you start by assuming that the DBMS must dynamically allocate storage for all object values no matter how simple?

>Why today java in RDBMS is just calling
>static methods?

I doubt that your statement is true for all current RDBMS implementations. In fact, didn't Carl criticize Lee's product for actually overcoming this limitation.

>>Why should vendors provide adequate physical independence when the markets
>>accept the status quo? Or even worse, when the markets assume that
 physical
>>independence harms performance?
>
>Do you really know how many conflicting goals query optimiser have?

Would you care to enumerate them? Have you ever considered that the ability to bias a product toward one conflicting performance goal or another provides a suitable means of product differentiation?

Of course, users cannot benefit from this if every product has a fundamentally different logical data model.

>Note, that during long product history, users listen to the buzz, and
 vendor has
>to react, otherwise, it would loose competitive advantage.

Unfortunately, the buzz is the problem I am trying to overcome. Or hadn't you noticed?

> And in order to get your query to
>perform you have to write it a certain way.

If your product fails to deliver adequate physical independence, complain to your vendor -- don't spread the myth that the logical data model is the cause.

If your vendor implements a redundant language such that different logically identical queries have extremely varying performance characteristics, either request they get rid of the redundancies of the language or request that they optimize all equivalents equally well

>In short, we have a product that [ignorant] users deserve.
Received on Thu Jul 19 2001 - 19:10:40 CEST