Is creating a table with 1000 partitions a stupid thing to do?

We are currently looking to create a very large table >100GB 100,000,000 rows, the only key we have that is always specified in every query is a customer id of which there is a range 1-1000. We are looking to partition the table based around this key. Most of the queries will be trawling the whole customers data, although some will also specify a date range, which we can index locally. Not all partitions will be in seperate tablespaces. This is a reporting database with a large number of online connected users running canned queries.

Questions:
Is there a better way of doing this?
What is the overhead of having a large number of parititions? Would standard index/clusters work better?

Many Thanks

Mike Received on Wed Jun 16 1999 - 04:10:23 CDT