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

In article <Ua057.81$YH1.29301777_at_radon.golden.net>, Bob Badour says...
>
>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?

>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? Why then relational vendors come up with cludgy object/relational implementations instaed of just implemnting java type based domains? Why today java in RDBMS is just calling static methods?

>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? I know, you tell me that SQL is deficient, but what query language do you suggest?

Note, that during long product history, users listen to the buzz, and vendor has to react, otherwise, it would loose competitive advantage. Yesterday, everybody thought CORBA interfaces are silver bullets, so vendor have to implement CORBA in the database. Today it's not hot anymore, so they scrap it. Tomorrow, everybody want's XML database, so vendor goes ahead and implements it as just another ugly addendum to relational database. Issues like why optimiser plan doesn't have monothonic selectivity on "where NAME like 'AAAA%'" are secondary, which only couple of users are aware of. And in order to get your query to perform you have to write it a certain way. So much for physical independence. In short, we have a product that users deserve. Received on Thu Jul 19 2001 - 04:25:00 CEST