Re: Hierarchical Relationship

From: <joe_celko_at_my-deja.com>
Date: 2000/03/19
Message-ID: <8b2o44$igf$1_at_nnrp1.deja.com>#1/1


>> ok, my explaination was rather brief: consider team-development, you
have to get a quick overview of "where you are" and what possible implications your changes will have. this prefixing gives you a first and imho valuable insight. can i make changes to this relation or is it a view which is not updateable etc.. <<

Why not follow the Metadata committee standards for naming data elememts? I think that this hides the overview that you need to understand the problem as a whole by immediately pushing you into the storage method and implementation.

>> i remember lectures about compiler construction where some students
really considered implementing symbol table management thru a database <bg> do you think this is reasonable? <<

Well, only if it is a really, really BIG symbol table ... or a really, really small fast database <g>. Hash tables are taught next quarter, I guess.

I am amazed that so many students today do not know about check digits, the design of encoding schemes, scales and measurements, and basic statistics. They really think that mousey-click is programming and design.

>> there are lots of scenarios where it makes sense to do the computing
on the serverside. implementing aggregate functions on the clientside is a rather suboptimal idea. <<

Agreed, but an aggregate is a set operation. I have a bunch of tricks for writing the "fancy ones" with the built-in aggregate operators and some simple library function calls.

>> how do you ensure to have a good query when the underlaying
optimizer is "cost-based" and statistics vary? <<

Let me make a gross generalization: In most applications, the ratios in the stats tends to become stable in the first year of operation. The plan, test runs and expereince with that particular product become your guide. If they fail, then get a tool and let it bang away onthe wuery until it comes up with something better (see LECCO and others).

Some days, you are just plain screwed. In SQL FOR SMARTIES, I give a few versions of Codd's Relational Division. One uses NOT EXISTS() preidicates and is generally attributed to Chris Date, and the other uses COUNT()operators. Depending on what percentage of the table is returned as the quotant, one or the other methods is faster.

>> am i the only one who is sick of this stuff and who is wondering why
there are still "obsolete" rule-based optimizers used in mission critical environments? not sure but i was told that even oracle financials does this :-) you think we should completely ignore whether we're dealing with views or tables? hmm <<

I hope that nobody is still using rule-based optimizers in the 21st Century!! At least nobody is still making sldie rulers ...

--CELKO-- Sent via Deja.com http://www.deja.com/
Before you buy. Received on Sun Mar 19 2000 - 00:00:00 CET

Original text of this message