On Fri, 2008-01-04 at 13:06 +0530, Gokulakannan Somasundaram wrote:
> a) This proposal would work for the kind of table organizations which
> are currently partitioned and maintained based on some kind of
> timestamp. Consider one of the use-case. A large Retail firm has a lot
> of stores. DBA maintains and updates the inventories of those stores
> in hash-partitions based on store-no. As the inventory gets updated,
> the corresponding partition receives the update and it goes like
> that..
> Here all the partitions are going to get constantly updated.
> So no partition can possibly become a read only partition. You have
> clearly called it out in your para. i am just re-confirming on that.
> Or do you have something for this in your soln.?
>
> To my limited experience, most partition strategies are based on some
> form of time-stamp. If the proposed soln. can cater to those, it has
> lot of use-cases.
I don't think it would apply to an Inventory table. That is a current
state table.
It is designed for any large tables that would grow naturally over time
if we left them to do so. Solutions that it would work for:
- any Fact table where measurements/observations/events are accumulated
e.g.
Web Hits (any Internet events)
Call Detail Records
Sales
Security Events
Scientific Measurements
Process Control
- any Major Entity where new entities are created from a sequence
e.g.
Orders, OrderItems
Invoices
Shipments, Returns
most SCM/DCM events
It's not aimed at any particular benchmark, just real usage scenarios.
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com