Question

I am am new to PHP/Databases… But I am picking it up fairly swiftly. What I would like to ask you guys is pretty simple. I want to normalize my database and am not positive how to go about it. I get the concept, but see multiple ways to do it. Figure I’d ask people with some experience.

Here is my Database (2 tables so far):
Brands
Products

***Brands Breakdown:***
1   id          int(6)
**Note:** Above, I will probably use 4-Letter codes for each brand instead of primary/int/auto.
2   name            text
3   logo            varchar(20)
4   phone           varchar(20)
5   website     varchar(30)
6   contact_name    text
7   contact_number  varchar(20)
8   contact_email   varchar(30)
9   warehouse       varchar(20)
10  pricing         varchar(15)
11  bio             varchar(300)

***Products Breakdown***
id (INT(6) / Auto_Increment)
brand (This is where I'll insert the four letter code for brand)
category (e.g. Brakes)
subCategory (e.g. Brake Rotors)
details (e.g. Drilled and Slotteed 'Razr')
sku (Part #)
minYear
maxyear
make (e.g. Subaru)
model (e.g. Impreza)
subModel (e.g. WRX STi)
description (Paragraph on part describing it)

specs (I imagine this can be expanded on. need cells somewhere for sizes / colors / engine codes / etc.)

msrp
jobber
price
cost
weight (of part)
warehouse (Could be moved to brand's table)
image (URL of image for the part)

---

So My main question is: Do I make each brand have there own table similar to my current ‘products’ table? or have ‘category’ tables? ‘subCategories’? How would you guys normalize this data?

I would like to have a solid database while I’m learning this stuff so I learn the right way. Any advice would be appreciated.

UPDATE:
To anyone who comes across this question who is trying to learn how to structure their database, one major thing I was unaware of when I asked this was something called “cardinality“. Research this topic and learn how to apply it to your database schemas!

Answer 1

Don’t make each brand have its own table. That’s not normalization, that’s partitioning. Don’t do that until your data base gets very large.

It’s not clear what your brand table means. I am guessing you mean parts-manufacturer, but I’m not sure. The rest of this discussion assumes that you do mean parts-manufacturer.

Here’s my suggestion.

Rename your brand table. Call it “Manufacturer” and split it in two, for Manufacturer and Contact.

Manufacturer:

mfrid (your four letter code, primary key)
mfrname            text
mrflogo            varchar(20)
mfrwebsite     varchar(30)
mfrphone           varchar(20)
warehouse       varchar(20)

Contact:

mfrid (four letter code)  (part of primary key)
contactid (autoincrement) (part of primary key)
contact_name    text
contact_number  varchar(20)
contact_email   varchar(30)
bio             varchar(300)

Why is “pricing” an attribute of the manufacturer? What do you mean by “pricing?” Isn’t it an attribute of an individual part?

Split your parts table into two. One table will have a row for each part sku. The other will have a table for each application (that is, each make and model of car in which the part may be used). Like so:

SKU:

sku (your stock-keeping unit number, primary key).
mfrid (maker of the PART, not the vehicle in which it fits, foreign key to mfr table).
mfrsku (the brand's stock keeping unit, not necessarily unique in your system)
category (e.g. Brakes)
subCategory (e.g. Brake Rotors)
details (e.g. Drilled and Slotteed 'Razr')
description (Paragraph on part describing it)
saleprice (?)
cost (?)

Application:

ApplicationID (auto incrementing primary key)
make (e.g. Subaru)
model (e.g. Impreza)
subModel (e.g. WRX STi)
firstYear.
lastYear.

Then, you’ll need a join table (because each Application can have zero or more SKUs and vice versa; that is, your SKU and Application entities can have many-to-many relationships). In your example, you know that multiple models of Subarus often take the same parts. This schema allows for that.

ApplicationSKU:

ApplicationID
SKU

The trick to normalizing is to understand your application domain. Figure out what entities you have: e.g.

1. manufacturers like Delco and Subaru
2. contact people like Joe and Harry
3. parts like Left Front Wiper Assembly and Rear Wiper Assembly
4. applications like 1999-2006 Subaru Forester and 1998-2007 Subaru Impreza

Create a table that matches each entity you have. Figure out how you will uniquely identify each entity (in other words, figure out what you will use for a primary key).

Create join tables when you have many-to-many relationships between entities.

Create foreign keys to connect the various entities together.

I hope this helps.