SGreen@stripped wrote:
> I agree with the basic design: one table for all of your basic objects
> (shirts, pants, coats, shoes, etc), one table for all of your attributes
> (see Barry's response), a sku table equating objects (differentiated by
> their attributes) and their inventory quantities (on hand, backordered,
> etc), and one more to relate SKU to all applicable attributes.
>
Hi All,
Shawn, what is a SKU?
> Each SKU represents one combination of a base object with a particular set
> of attributes. IT's the SKU number that important for inventory control
> and that will uniquely identify a size 8 pair of jeans from a size 9 pair
> or a pair of black size 8s from a pair of red size 8s all in the same
> style (cut) from the same manufacturer
>
Makers:
maker_id
maker_desc
Products:
prod_id
prod_code
maker_id
prod_desc
attri_id
object_id
Attributes:
attri_id
attri_desc
Objects:
object_id
object_desc
That is where I got to, as I've never done this kinda design before.
Thrown into the deep end, I guess. May I ask for more assistance with
this? Where does the quantity go? Any tutorials on this kind of design?
Cheers.
Mark Sargent.