Re: Index compression vs. table compression

Jonathan Lewis wrote:

>Fortunately that's a front-end thing, not a database
>thing, so we can sympathise with you without
>having to tell you how to fix it. ;)

Fortunately I'm not using Oracle Forms these days so I don't really care :-) But I sympathize also, and sometimes bring it up in case I ever have to again. The problem is, after all, part of OAS10g.

>Ah! the old "I don't know how to do a proper design,
>so I'll let the DBA sort out the problems." strategy
>so loved by 'database independent' apps.

I do have to disagree here, it is used by "enterprise software," which may or may not be db independent. It can be quite proper relational design. In fact, having a bunch of EMPLOYEE tables in different schemata that need to be joined (for example) might not be such a great design, eh? That would be using different schemata for an attribute (you have multiple divisions, say) that proper design would say is of primary importance towards the EMPLOYEE table. Proper design means anticipating ahead of time the problem domain.

>Oh, I see a problem

has this bit:
>you may find that you need to adopt an index naming
>convention that makes your indexes appear in order
>of desirability when you list them alphabetically.

A "db-independent" tool I use has had this idiot-syncracy for many years as RBO. I am highly entertained to see your comment in the context of CBO.

jg

--
@home.com is bogus.
Good flame wars:  http://www.osnews.com/story.php?news_id=9501