| SGreen@unimin.com 2006-04-06, 9:29 am |
| --=_alternative 004C9E0385257148_=
Content-Type: text/plain; charset="US-ASCII"
Barry <Barry@flyerheaven.de> wrote on 04/06/2006 03:52:53 AM:
> Mark Sargent wrote:
[color=darkred]
[color=darkred]
to[color=darkred]
every[color=darkred]
products[color=darkr
ed]
> Jeans- 48_W0QQitemZ77571250
46QQcategoryZ11483QQ
tcZphotoQQcmdZViewIt
em
table[color=darkred]
[color=darkred]
am[color=darkred]
[color=darkred]
>
> Uhm.
> My solution would be 3 Databases where one has ID,Attrib_object_id,
> Attrib_name_id, Attrib_value
>
> And the other two would be an attrib database and an object databse.
>
> Yep, something like that.
>
I think you meant to type "tables" not "databases" - :-0 But we knew
what you meant... ;-)
> --
> Smileys rule (cX.x)C --o(^_^o)
> Dance for me! ^(^_^)o (o^_^)o o(^_^)^ o(^_^o)
>
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.
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
It's a time-tested inventory control model used by all but the smallest of
retailers.
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
--=_alternative 004C9E0385257148_=--
|