Re: debunking partitioning

Ok .. just one example ... tell me how would you do a similar of hash partitioning .. using partitioned views. Or don't you think a global/local index is easier to maintain than separate indexes on hundreds of other tables. .. or just that seeing one table in your data dictionary makes more sense than seeing hundreds of them.

You think creating and maintaining a trigger is worth the headache?

Anurag

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:fVsH9.10$T1.130_at_news.oracle.com...
>
> "Anurag Varma" <avdbi_at_hotmail.com> wrote in message
> news:uus05tk7t3ba43_at_corp.supernews.com...
> > In case you are interested
> > Jonathan Lewis has a good comparison/comments on partitioned tables and
> partitioned views in his book Practial Oracle8i ....
>
> Thanks Anurag: I found Jonathan's article on google. His analysis is much
> more comprehensive, of course. Couple additions:
>
> 1. Partitioned Views and Partitioned Tables are logically the same thing.
> Therefore, there is no reason for one being fundamentally "more performant"
> than the other.
>
> 2. I don't quite understand why Jonatan associates the query
>
> where partition_col between a and c
> or partition_col between c and d
>
> to the "compare this year and last year". The latter is a selfjoin query
>
> select a.*, b.* from sales a, sales b
> where a.year=1999 and b.year=2000
> and a.day=b.day -- day-by-day comparison
>
> which doesn't have any ORs in it, right?
>
> 3. Partition maintenance independence could be easily acheved with
> Partitioned Views too. When a user issues a DDL a system trigger rewrites a
> Partitioned Views so that it doesn't include the altered table anymore. All
> queries go against the "valid" partitioned exactly as in the Partitioned
> Tables case. After completion the table is added back.
>
> 4. In general, Oracle has been criticised for creating logical concepts
> without solid justification. Any new logical concept adds a cost for users
> that have to learn it. Look at the documentation volume! Some cases, like
> "analyse" existing together with "dbms_stats", are just plain ridiculous.
> Partitioned tables is just yet another, although arguably more subtle,
> example.
>
>
Received on Thu Dec 05 2002 - 00:43:23 CST