Question

Before I go asking more questions about the coding, I’d like to first figure out the best method for me to follow for making my database. I’m running into a problem with how I should go about structuring it to keep everything minimized and due to its’ nature I have lots of re-occurring data that I have to represent.

I design custom shirts and have a variety of different types of shirts for people to choose from that are available in both adult and child sizes of both genders. For example, I have crewneck shirts, raglan sleeves, ringer sleeves and hoodies which are available for men, women, boys, girls and toddlers. The prices are the same for each shirt from the toddler sizes up to 1x in the adult sizes, then 2x, 3x, 4x and 5x are each different prices. Then there’s the color options for each kind of shirt which varies, some may have 4 color options, some have 32.

So lets take just the crewneck shirts for an example. Men s-1x, Women s-1x, Boys xs-1x, girls xs-1x and toddlers NB-18months is a total of 22 rows that will be represented in the table and are all the same price. 2X and up only apply to men and women so that’s 8 more rows which makes 30 rows total for just the crewneck shirts. When it gets into the color options, there’s 32 different colors available for them. If I were to do each and every size for all of them that would be 960 total rows just for the crewneck shirts alone with mainly HIGHLY repeated data for just one minor change.

I thought about it and figured It’s best to treat these items on the table as actual items in a stock room because THEY’RE REALLY THERE in the stock room… you don’t have just one box of shirts that you can punch a button on the side to turn to any size of color, you have to deal with the actual shirt and tedious task of putting them somewhere, so I deciding against trying to get outrageous with a bunch of foreign keys and indexes, besides that it gets just as tedious and you wind up having to represent just as much but with a lot more tables when you could’ve just put the data it’s linking to in the first table.

If we take just the other 3 kinds of shirts and apply that same logic with all the colors and sizes just for those 4 shirts alone there will be 3,840 rows, with the other shirts left I’m not counting in you could say I’m looking at roughly 10,000 rows of data all in one table. This data will be growing over time and I’m wondering what it might turn into trying to keep it all organized. So I figured maybe the best logic to go with would be to break it down like the do in an actual retail store, which is to separate the departments into men, women, boys, girls and babies. so that way I have 5 separate tables that are only called when the user decides to “go to that department” so if there’s a man who wants the men shirts he doesn’t have 7,000+ rows of extra data present that doesn’t even apply to what he’s looking for.

Would this be a better way of setting it up? or would it be better to keep it all as one gigantic table and just query the “men” shirts in the php from the table in the section for men and the same with women and kids?

My next issue is all the color options that may be available, as I said before some shirts will have as few as 4 some will have as many as 32, so some of those are enough data to form a table all on their own, so I could really have a separate table for every kind of shirt. I’ll be using a query in php to populate my items from the tables so I don’t have to code so much in the html and javascript. That way I can set it to SELECT ALL * table WHERE type=men and it will take all the men shirts and auto populate the coding for each one. That way as I add and take things to and from the tables it’ll automatically be updated. I already have an idea for HOW I’m going to do that, but I can only think so far into it because I haven’t decided on a good way to set the tables up which is what I’d have to structure it to call from.

For example, if I have all the color options of each shirt all on the same table versus having it broken down and foreign keys linking to other tables to represent them. that would be two totally different ways of having to call it forth, so I’m stuck on this and don’t really know where to go with it. any suggestions?

Answer 1

I know you don’t want to break it out into separate tables, but I think going the multiple table route would be the best. However, I don’t think it is as bad as you think. My suggestion would be the following. Obviously, you want to change the names of the fields, but this is a quick representation:

Shirts

  - id (primary key)
  - description
  - men (Y/N)
  - women (Y/N)
  - boy (Y/N)
  - girl (Y/N)
  - toddlers (Y/N)

Sizes

  - id (primary key)
  - shirt_id (foreign key)
  - Size

Colors

  - id (primary key)
  - shirt_id (foreign key)
  - Color

Price

  - id (primary key)
  - shirt_id (foreign key)
  - size_id (foreign key)
  - price

Having these three tables makes it so that you won’t have to store all 10,000 rows in one single table and maintain it, but the data is still all there. Keeping your data separated into their proper places keeps from replicating needless information.

Want to pull all men’s shirts?

SELECT * FROM shirts WHERE men = '1'

To be honest, you should really have at least 5 or 6 tables. One/two containing the labels for sizes and colors (either one table containing all, or one for each one) and the other 4 containing the actual data. This will keep your data uniform across everything (example: Blue vs blue). You know what they say, there is more than one way to skin a cat.