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

You start by claiming that SQL is not necessarily to blame and then you introduce specific SQL syntax and limitations?!?

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

First, using functional dependencies, one determines the minimal set of constraints one must check to ensure coverage of all constraints.

Second, one constructs a relational expression that fully describes the update to perform including all constraint checks.

Third, one applies known mathematical identies to transform the expression into a well-defined canonical form.

Fourth, one applies known mathematical identities to transform the expression into logical equivalents that might improve performance. (For instance, pushing restrictions through join criteria onto as many pre-join relations as possible or simply permuting the order of sub-expressions.)

Fifth, one examines other declared integrity constraints looking for any that might aid optimization and uses them to further transform the permuted form.

Sixth, one examines the available access paths that evaluate the given expressions estimating cost looking for a minimal cost.

The fourth and sixth steps are just an exercise in dynamic programming optimization augmented by the fifth step -- many computer science texts cover the topic of dynamic programming in varying levels of detail.

If the expense at runtime exceeds the constraints of the required solution, use statically compiled access paths optimized at compile-time.

As for blaming SQL, in five of the six steps above the solution depends on known mathematical identities many of which apply for relations but do not apply for SQL tables primarily due to duplicate rows, NULL etc.

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

I did not have the dbdebunk quote in mind. You seem to defend the quote a little. Are you aware of the premise behind the quote of the week?

'A Quote-of-the-Week on DEBUNKINGS normally contains a pronouncement by database vendors, practitioners or "experts" blatantly exposing their lack of knowledge of relational fundamentals. '

If the vendor in question has poor support for maintaining foreign key constraints, I do not find the conclusions from the 'release folks' regarding difficulty in the least bit surprizing (even if they are a little misplaced.)

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

Okay, we now know what you are not doing. What are you doing?

>>>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 not the even huger codebase of C++ classes? Or SmallTalk classes? Or...?

>>>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 make any distinction among primitive and non-primitive data types at all?

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

What is not clear about it? The fact that optimization necessarily balances often conflicting goals provides a basis on which products can compete, establish niche markets etc.

Consider the user who wants to benefit from the competition and discovers that a niche product ideally conforms to their performance needs. If the user's applications were written for a different product based on a fundamentally different logical data model, the cost of adopting the niche product increases dramatically.

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

Nope. No time for such things. I have products to deliver, taxes to file and fish to catch.

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

Huh? Say it to the vendor and it is 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.

I assume that vendors are aware of the fundamental importance of the logical data model. I also assume vendors are aware how ignorant their customers are of same.

If the customers do not demand it -- no matter how important it is -- the vendor will not deliver it. If ignorant customers are actively repulsed by it, the vendor will take extraordinary measures to deprive them of it.

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

..due to market ignorance, prejudice and misconception. Is your "solution" to reinforce the ignorance, prejudice and misconception? Does that seem a worthy goal to you? Received on Thu Jul 19 2001 - 21:27:01 CEST