Re: Index compression vs. table compression

From: DA Morgan <damorgan_at_x.washington.edu>
Date: Tue, 25 Jan 2005 16:06:25 -0800
Message-ID: <1106697833.293948@yasure>

Joel Garry wrote:

> DA Morgan wrote:
>
>
>

>>IF / ELSE / END IF;

>
>

>>But a very bad design: One table named postal codes will suffice.

>
>
> Right. What I'm saying is you probably want to have the attribute of
> country as part of the key, since you don't know that every country in
> the world will have, uh, globally unique postal codes. And more
> generally, what used to be small lookup tables now have similar key
> compounding, so they are not small anymore. The only time I _don't_
> see this is small, newly designed standalone apps. Which of course,
> are done with front-end tool-of-the-month these days. Perhaps others
> see large apps with small lookup tables, but I don't. How much of that
> is due to my experience-slant, I couldn't say. Judging from what I see
> on the web, I think many programmers don't think the postal code
> through, either they only use referential integrity on their local
> country, or just leave everything free-form. But hey, does every
> country have postal codes?
>
> jg
> --
> @home.com is bogus.
> Lost a full billable hour in the post office this morning, picking up
> the OpenWorld disks.

If you read the various postings to this group by everyone from Tom Kyte to Jonathan Lewis to Richard Foote, et al one thing is common to all of them. A table, no matter its size, with proper statistics for the optimizer, in which you query based on the PK is going to not do an FTE. It matters not if the column as 25 rows or 250,000,000 rows.

<APOLOGY IN ADVANCE>
And given the flammability of this thread I sure hope I didn't say anything incorrect or I will never hear the end of it. </APOLOGY IN ADVANCE>

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)

Received on Tue Jan 25 2005 - 18:06:25 CST