Re: Advice on SQL and records

"FRAN" <fran_beta_at_hotmail.com> wrote in message news:1124756544.927652.224000_at_f14g2000cwb.googlegroups.com...

> I'm learning so much here. Thanks everyone. I hope I don't sound like
> an ignorant moron, but frankly, I'd much prefer to run that risk here,
> than in front of a class, especially when I might spread my own
> ignorance about prior to assessment.
>

Oh boy! Can I ever relate to this! There's no test quite so severe as the one you face in front of a class, at least if you care.

When I first started as an instructor there were things I thought I knew pretty well, until I got up to talk about them. It generally took me about 3 times teaching the same material before I felt comfortable with it. And the stuff I taught was short, intensive courses, about 40 hours of class and lab in one week.

I'm going to drop the somewhat ironic persona I tend to adopt in this discussion group, and try to give absolutely straight answers to your questions. However, be warned that I tend to go off on tangents, and a few of those tangents really contain the nuggets of wisdom.

Before I get down to the specifics of your question, I want to talk a little about the question behind the question. Why do you need to know so much about the cardinality of the tables, anyway?

About ten years ago, the answer was, typically, "because the Oracle optimizer is so bad". Before they came up with the CBO, they had a thing called the RBO. The RBO used to look at the order of the tables in the "FROM" clause, and take that as subtle hint about the order in which to perform the query. This meant that the Oracle programmer had to know a lot about the cardinalities (number of rows) in the tables in order to name the tables in a good order.

Even back then, there were products with much better optimizers. One of them, DEC Rdb/VMS, was bought out by the Oracle company in 1994. The DEC optimizer provided a lot of the ideas that eventually found their way into the Oracle CBO.

Sorry for the long digression. I'll deal with the case you raise in a separate response. Received on Tue Aug 23 2005 - 15:04:41 CEST