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

In article <9EE57.162$8p5.42787964_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?
>
>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.

It is not nesessarily SQL that I would blame in this particular case. Today, check constraints are allowed to depend upon single row only, because it is pretty much clear that touching a row requires revalidating just the check constraints on that one row (okay, tuple, if you insist).

Foreign key constraints are more complicated, but again, there is more economic solution than just a full table scan per each update transaction. Now, do you know the solution in general case, that is easy to implement, and not expensive at runtime?

>I suppose your solution is to not check any constraints?

If you have last quote of the week on dbdebunk site in mind, I happen to know the vendor. Those "discoveries" were made by the release folks who found that foreign key constraints are hard to maintain. They are unable to change their position, even though the latest dbms releases invalidate most of their complaints.

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

I'm not challenging your assault against OODBMS here.

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

Name other popular object language. When object language defined in 3rd manifesto would be released? Until then, I would have to think how to make my RDBMS domains to natively support huge codebase of existing java classes.

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

If we are talking about SQL databases, then the first limitation to overcome is to make at least all primitive datatypes to be the same. And given that java.lang.String and java.sql.Timestamp are not primitive, user defined datatypes as well.

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

I admit that quality of todays optimizer is more influenced by huge implementation codebase and reluctance of the optimizer owners to change things, rather than, say, nonorthogonality of SQL itself. Let see if clean starters, like Lee, would be able to come up with superior product.

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

Would you be so kind to clarify your statement?

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

I assume that you are writing a book "Relational Data Modelling for Object folks" in the background. If you succeed translating all object modelling concepts (if there is such a thing) into relational ones, you'll get 5 stars amazon rating. If your starting point would be what relational model is and why normalization is important, the rest of the programming world would continue to think that "everything is an object".

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

That's easier said than done. Every user demand something from vendor, and vendor has no way to please them all. If vendor were aware of fundamental importance of logical model, they would never prioritize corba or xml ventures.

>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

Can say hardly anything new here: the problem is that minority of users may be aware of and demand this, while the rest is looking for some "killer" features. Consistent optimizer is not a hot topic nowadays. Making normalization and constraints sexy again, anybody? Received on Thu Jul 19 2001 - 20:31:10 CEST