Think of each row entry to a table as an object.
for instance:
you have a table called cars with huge rowlengths with all the details ...
lots of details would get stored double.
for isntance, car brand, or motor size, or just imagine if you would have more then 1 set of tires that could fit. Would you make an entire row entry with double values just to store those extra tires ?
no, chop it up, and link items by their IDs.
Example:
I want a car, listed with a brand, and want to know which tires fit under it.
We get cars, brands, tires.
Table my_cars
-id : auto increment - key
-brand : int (id car brands)
-tire : int (id tire_sizes)
Table car_brands
-id : autoincrement - key
-name : var char - car brand name
Table tire_sizes
-id : auto increment - key
-size : int - set size
Assuming you have rows entered in car_brands, (names with IDs) and rows added to tire_sizes (Sizes with IDs)
when adding a my_cars, you can pick the ID from the corresponding table,which gives you a reference.
This principal can keep your datanbase really small and fast.
heres a rough version of a possible query:
select tire_sizes.size as tiresize,car_brands.name as brandname from car_brands, tire_sizes where car_brands.id = my_cars.brand and tire_sizes.id = my_cars.tire and my_cars.id = 'MyChosenId'
when done $var->brandname and $var->tiresize should give the table linked data :)
your my_cars table would merely be storing every row, the IDs as reference to the items.
These tables are small, but if you have lots of data in lots of tables, this will really come in use.
There are lots of framework who use this sort of system through primary keys and indexes (INNODB)