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

In article <0EG57.169$SY6.43896842_at_radon.golden.net>, Bob Badour says...
>
>>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?!?

Not at all. The ease of checking if a tuple attributes meet a predicate condition has nothing to do with sql.

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

Are functional dependencies a part of schema definition? Are all constraints functional (well, or join if you like)? Are you aware that it is expensive to infer dependencies from the set of the data?

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

Relational expressions describe the static view of the world. How would you define the "update" expression: before and after conditions?

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

Is there a well known canonical form -- the DNF of relational calculus? If there is, please, make sure that the algorithms that transform arbitrary expression into it have desired performance.

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

I don't understand. Away from canonical form? Isn't there a combinatorial explosion that awaits us just around the corner?

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

Overall, you seem to suggest that data modification might become as complex as quering if we implement general constraints. Now, if you happen to lock some data in the process, your transactional throughput will suffer.

You might object that this must necessarily happen because this is logical model and there is no way, to overcome this semantics. Skipping constraint checking implies that this concurrency logic must be maintained by application. I don't really know how valid this speculative argument is.

I hope I'm not provoking "don't put words in my mouth" reaction.

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

Strawman. Tables themself almost never contain duplicates. What do you think primary keys are for?

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

I'm not defending the quote. I just failed to prove them anything.

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

Coloring your black-and-white position.

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

In the bookstore where I went last time, java literature weighted the same as the others combined.

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

Because it is much easier to describe relational operators over primitive datatypes, as they could be certainly treated as values. It requires some effort to treat user-defined datatypes as values as well.

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

Say it to the vendor and be ignored.

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

Really? Last time I spoke to their architect he was convincing me that adding/dropping an index must affect query result set. Never mind difeerence between key constraints and indexes.

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

I dont think closed customer/vendor model is healthy anyway. Look at phone companies, energy utilities. It needs an external flow of inventions - like mobile phones.

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

Am I sellng short relational? Just adding some color to the picture. Received on Thu Jul 19 2001 - 23:54:51 CEST