"Anurag Varma" <avdbihotmail.com> wrote in message news:<uuttcvgh0vm7cdcorp.supernews.com>...
> Ok .. just one example ... tell me how would you do a similar of hash partitioning .. using partitioned views.
Hash partitioning into 3 tables T_1, T_2, T_3:

create view T as
select * from T_1
union all
select * from T_2
union all
select * from T_3

CREATE OR REPLACE TRIGGER T_insert
INSTEAD OF INSERT ON manager_info
REFERENCING NEW AS n
FOR EACH ROW
DECLARE
rowcnt number;
BEGIN
IF dbms_utility.get_hash_value(n.partitioned_col,1,3) =1 THEN
INSERT INTO T_1;
ELSE IF =2 THEN
INSERT INTO T_2;
...
END

> Or don't you think a global/local index is easier to maintain than separate indexes on hundreds of other tables.
domain index would do.
> .. or just that seeing one table in your data dictionary makes more sense than seeing hundreds of them.
no difference: there are hundreds of partitions in the dictionary.

If you are complaining about the size of information your dictionary
query returns, you need to fix the query -- for example add
aggregation so that it will return just one string

T1..T100

instead of full list of tables
> You think creating and maintaining a trigger is worth the headache?
It could be hidden below the hood. I, as a user, am not supposed to
develop all the partition mechanics, right? And also partition syntax
could definetely be more concise than partitioned views. This is
something that users would be happy delegating to oracle to design.