Partitioned Tables Was: [Bulk] Re: Getting DDS for a DDL Generated File (or convince me its unnecessary)

<BuckSnip>
Personally, I would be fighting and kicking to avoid working with
multi-member files
</BuckSnip>>

<LuisSnip>
I concur wholeheartedly. I have forgotten when was the last time I had to
work with muilti-member files...And really don't have any inclination to
refresh that kind of knowledge :-)
</LuisSnip>

I can see some places where "partitioned" (aka members) tables may be
useful.
There are some things I've seen recently in which IBM recommended them.
You can read "the SQL way" with them in the Knowledge Center by studying
the partitioning clause on the create table statement.
For example, lets say you have multiple IBM i lpars, on different physical
servers. Maybe even one in each warehouse. You could partition by
warehouse code and it would automatically put that particular partition on
the appropriate server. You insert a row using warehouse MX perhaps. And
your MX warehouse is in Jaurez Mexico, and you have an IBM i in Jaurez. It
could automatically be set up to put that row into a partition(member) on
that server.
You could partition locally into the same database/schema/table by year.
Make dropping history quite easy.
However, even for local partitioning, you have to purchase DB2
Multisystem. This is a seperately priced option of 5770SS1. I would like
to see IBM unbundle local partitioning from DB2 Multisystem and I have
submitted a DCR for that.

This kind of partitioning avoids all that "alias" and OVRDBF garbage.


Rob Berendt