Re: Advice on SQL and records

From: David Cressey <>
Date: Tue, 23 Aug 2005 13:25:16 GMT
Message-ID: <0tFOe.749$>

"FRAN" <> wrote in message
> > A better question might be whether the optimizer can use the
> > cardinality of the tables, at the time of the query, in addition to
> > cues, to pick the best strategy for performing the query.
> What does "cardinality" mean? What's an "optimizer"?

The cardinality of that table is the number of rows in the table.

 The order of a table is the number of columns in it. "order" is a poor choice of terminology, since many people will read it as "Sort order".

This is the terminology I've seen. More than once, I've been roasted in this forum for using terminology that's different from the terminology some erudite sophmore is accustomed to. Terminology is a mess. What can I say?

An optimizer is a software component of a relational DBMS that determines which, among several candidate strategies, is the "best" strategy to use when carrying out a request. Typically, query optimization is the most critical, but I've used the term "request" in order to cover the other cases.

The quality of the optimizer can affect the time needed to perform the query by factors of ten to one or up to sixty to one.

The difference between a query that takes a minute, and the same query taking an hour, can make the entire difference between an on-line application and an off-line application. I suppose the same goes for a query that takes a second, as opposed to one that takes a minute.

> Thanks once again.
You're welcome.

BTW, I'm no theorist. I only hang out in this forum because there is no newsgroup for "database design" that's not product specific. There is a LOT of theoretical discussion in here that's over my head. BUt I do have a good background in making products like Oracle work, and work well.

My own philosophy is to follow simple and sound design, not worrying too much about performance. Then, tune when necessary. However, there's an important difference between "simple" and "too simple". Received on Tue Aug 23 2005 - 15:25:16 CEST

Original text of this message