Results 1 to 5 of 5
  1. #1
    Join Date
    Mar 2013
    Posts
    9

    Question Unanswered: Database for Clothing Order

    Hey everyone, I'm trying to put together a database for a clothing order for the company I work for.

    The catalog the employees are choosing from has about 20 items, with a total of 384 variations (colors, sizes, prices).

    What I'm trying to figure out is how to set my form up so the combo boxes will show the correct options for the selected item. What my boss wants is, essentially, what you would get when you go to a clothing website to order something, but I can't fit all the pieces together.

    I've tried creating an item table with all 384 variations, and an item table with the 20 items linked to subtables, and I can't seem to get either of them to work.

    If anyone could point me in the right direction I would greatly appreciate it.

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    depends on the level of detail
    but my approach would be similar to the attached PDF

    effectively table product is a header table that describes the overall product type, where as the detaisl of tthe actual product are in ProductDetials

    so say you had a series of printed teeshirts
    the design would be defined in Products, but the colourways and sizing in ProductDetails, along with a price.
    for my purposes I'd want ProductCategories to be self referencing so you could have say clothing, footwear and accesories as top level categories
    under that you'd have wahtever subdivisions you'd needs.
    say footwear, might have Adult & Childrens, and under those Male, Female or indeterrminate for each
    the idea of the link between sizing and product categories is to find a way of enforcing some form or RI check so that you have only the appropriate sizes for that type of product (ferinstance in category shoes you might want to limit to specific sizes. however it isn't modelled properly as the way its drawn out you'd need a size chart for each product category with products as opposed to say the supercategory. as sketched out you couldn't define all mens shoes as sizes 40,41,42....? in a single size definition group youd have to do it for every level of mens shoes. its doable but not as laid out there.

    I might be tempted to implement some form of colour classification if I though the shop required it eg its brown part of browns (or 'autumn colours'

    ultimately this depends on what your requirement is. and part of that ids driven by the shop. the way the shop sees its products may not be the same as its customers. ferinstance your customers may decide they want to know what footwear you have in their size (so they may not want to look at boots, then shoes, then trainers. they may just want ANY footwear in size 46. whereas the shop may be interested in what footwear is selling, or profiling what sizes/designs sell.
    Attached Files Attached Files
    I'd rather be riding on the Tiger 800 or the Norton

  3. #3
    Join Date
    Mar 2013
    Posts
    9
    Thanks for the input.

    The big problem I'm having is that the price changes for each item with the size. So, for example, a small to extra large shirt costs $5, but that same shirt sized double extra large costs $5.72, and so on...

    What I'm trying to accomplish basically is a simple interface that would allow me to pick the item number, and that item number would pull up a description, the colors available for that item, and the sizes with the appropriate prices.

    Again, thanks for the input and diagram, I think it has me going in the right direction.

  4. #4
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    The big problem I'm having is that the price changes for each item with the size
    And the problem is?
    that model support the storing of price agaisnt a specific instance of the proiduct (ie a specific product, of a specific size and a sepcific colour and a specific whatever else is required to identify a stock item.

    What I'm trying to accomplish basically is a simple interface that would allow me to pick the item number, and that item number would pull up a description, the colors available for that item, and the sizes with the appropriate prices.
    again what is the problem?
    someone somewhere has to do the piece of work that identifies what your actual products are. having doen that the final selection screen is realtively trivial
    you could do it so many ways, but one way is

    a form with a combo that lists products
    once a user has selected a product then find all product details for that product
    if required you could use additional filters such as size, colour or whatever and then return all variants of that product (the product details)

    or you coudl query the db for all garments in a specific colourway, or all footwear that is, say boots.

    what tends to drive these things is what is required by the business. who is consuming the data, what processes do they go through when consuming the data. how do they want the data salami slicing to meet their requirements


    A stock controller may want to know what products are are availabel and approaching minimum stock levels

    a floor manager may want to know what stock they have in the ready use storage

    a customer may want to know what designs of tee shirt do you have in my size

    like incest, its relative
    I'd rather be riding on the Tiger 800 or the Norton

  5. #5
    Join Date
    Mar 2013
    Posts
    9
    Ok, I got it!

    Thanks again.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •