On Tue, 2002-07-30 at 13:42, Chris Albertson wrote:
> 2) The clasic design for an inventory system keeps a count
> of the widgets of each type on hand so you don't actually need
> to compute (count(widgets_bought)-count(widgets_sold)) to
> know how many are left. I think it is OK to keep some infomation
> pre-computed if it is needed frequently. Recovering the count
> from a datestamped transaction log seems like a lot of work.
The reason I thought this might be the way top go is the complaint from
the customer about every other system he has looked at.
The business is shoe retail, so he buys a shoe, say it's called "Trek"
made by "Joes Shoe makers". When He buys 400 of these, they might be
200 white, 100 black, 100 red, but also spread accross 10 different
sizes.
On other systems he has had to have aproduct code for each possible
combo, one for wihte size 35, one for white size 35.5 etc.
Then he cant get a count of how many "treks" he has in stock. I
fuggured this way I can give a simple "389 total treks in stock" answer,
or a "137 white treks" or a "24 white size 35 treks".
As you say it's quite fast, I have entered 25,000 random transactions
and getting a query run in 0.21 seconds (from a python interface).
It seems like a good plan, but I am not experienced in these things...
--
*
* Rob Brown-Bayliss
*
