Re: Index compression vs. table compression

Noons wrote:

>You know what I mean: user types a
>single letterfollowed by % to get all
>the postcodes starting from that letter,
>then picks the one they want and the
>real PK (the postcode number itself)
>gets copied somewhere else. I have
>Forms applications in mind here.

Interesting point brought up here. I've long thought Oracle is kind of stingy in it's LOV. For example, I think looking up a product code you should be able to easily filter on various related fields, like "I'm entering an order and I need to know the exact part code in division 23 for the part with a description like '%MARITAL%AID%'," as opposed to some form LOVs I've seen where you have to scroll through n-thousand parts to get to the right screen. So to me, there really is no such thing as a small lookup table anymore, I rarely see anything like Daniel's example (even a "parameter" table I'm looking at has thousands of rows). I'm fortunate that the tool I use makes it trivial to do such things, since what used to be small lookup tables have inevitably had a composite key prepended to allow multiple companies/divisions/countries/language/whatever. From a performance standpoint, the LOV and the FK both have someone waiting for them after entering data on a screen, although sometimes LOV response-times can be said to be less important.

I also liked Richard's recent simplified explanation of the low percentage of rows to trigger an FTS, I thought it kind of explained the default of the optimizer_index* parameters, although now I need another explanation why they need to be changed... :-O

jg

--
@home.com is bogus.
firegoogle:  http://weblogs.mozillazine.org/ben/archives/007366.html