Partitioning Strategy for Fact and Dims in Oracle/DB2/Sybase

Please specify the partition strategy you follow in your organization for facts and dims in Ora/Sybase/Db2

Thanks,
bi_at_nj

Date is the most common partitioning criteria for fact tables. I have not seen a situation where dimension tables were partitioned, and, by their nature, any partitioning would be specific to a particular application.

If you do partition your dimensions, date is also the most common partitioning attribute. For my Customer dimension, I keep all active customers in one partition. All the history is kept in a separate partition.

BoxesAndLines wrote:If you do partition your dimensions, date is also the most common partitioning attribute. For my Customer dimension, I keep all active customers in one partition. All the history is kept in a separate partition.

B&L:
Your customers are partitioned by status, not date (although you may use a date field as a status indicator...). I was hesitant to say date is common for dimensions, becuase for dimensions, date does not have as definitive a meaning. It is not particularly useful for archival purposes because you can't roll off old rows unless you also roll off corresponding facts. And even if a dimension row is old, it doesn't mean it isn't used.

If I needed to partition a dimension table, I would be more inclined to use some kind of random/round-robin method (such as the mod of the primary key) to distribute the rows evenly across partitions, with local indexes, so that any query against the table would be handled in parallel. I would be less concerned about age of the row because it doesn't matter much from a table maintenance or performance standpoint. With that said, I would bet there are probably very valid cases where date is the perfect partitioning criteria for a dimension table... I just can't think of one... (note: foreign exchange rates are technically modeled as fact tables. Just in case someone was going to suggest that...)