Table Structure

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Let's say I have t-shirts in my table: Blue, Red, and Green (S, M, L).  Is it
better to create a table with each shirt as a product that includes S M L
fields, or should each size be its own product (Blue S, Blue M, Blue L)?


Re: Table Structure

Quoted text here. Click to load it

Wouldn't that be *NINE* products?  Blue Small, Blue Medium, Blue
Large, Red Small, Red Medium, Red Large, Green Small, Green Medium,
and Green Large?  I just can't see "S" as an abbreviation for "Blue".
Oh, yes, there's t-shirts in several styles, too, (probably with
different prices) along with any imprinting or logos.

How are you using the table?  From the point of view of your
*catalog*, the T-shirts may be one product, with options of size
and color.  From the point of view of *inventory*, you have different
inventories of 9 products, assuming that you don't have 3 sizes of
White T-shirts and dye them yourself as necessary for the order.
Are you just accepting orders, or are you also tracking inventory
and stock levels?  

You might also find that there are some products you make out of
several inventory items (for example, the local supermarket sometimes
makes a "Ketchup Lover's Pack" or "Family Pack" by taping three
bottles of Ketchup together with packing tape and affixing a new
price tag somewhat less than three times the price of an individual
bottle).  You could also sell many kinds (e.g. 9 times the number
of NFL teams) of sports team T-shirts, which consist of the t-shirt,
an iron-on logo for the team in question, and you iron-on the logo
before shipping it.  Your inventory has 9 kinds of T-shirts, plus
(however many NFL teams there are) kinds of logos.

A certain clothing warehouse I use doesn't stock pants with finished
pant legs.  You give them the inseam size, *then* they finish it and
ship it.  Saves on them having plenty for short and/or tall people, but
out of that style for average people, or vice versa.

Even if you are just accepting orders on a web site, a good storefront
web site will tell customers whether something is in stock, at least
to the level of good stock, stock getting low, and out of stock.
(What constitutes "getting low" depends on the product.  5 gallons
of (cow) milk at a grocery store may be VERY low.  5 gallons of
goat's milk may be more than you sell in a year, and you never stock
that much because most of it will spoil before you sell it.)

You don't have to implement a real-time system that can deal with
items going out of stock while the customer reads the page (but I
suspect the better stores do dynamic updates when orders come in),
or stock becoming available because someone cancelled an order, but
if it's been out of stock for a week, and it will take a month to
get more, tell the customer.  Your call whether you let him backorder
or make him wait.  Or maybe he'll just choose a color you DO have
in stock.  Perhaps you just update the stock level status every
night (stock level = quantity on hand - amount needed for pending
orders that haven't shipped yet).  You might still occasionally
have to tell a customer that inventory got sold out from under his
accepted order.  (Then every year or every few months you do a
physical inventory to find out what employees have been stealing
and the warehouse rats have been chewing up and using for nesting

Site Timeline