Not usre that I follow all of your post, but I do know the basic things you should be doind because they apply to all DB design.
1 Normalise your data
You need a categories table
table cats
cat_id autoinc primary key
category_name char or varchar
header char or varchar
additional fields
table products
prod_id autoinc primary key
sup_id int indexed
product char or varchar indexed
price decimal
additional fields
table suppliers
sup_id autoinc primary key
supplier char or varchar indexed
additional fields like contact details
table prod_cat
prod_id int indexed
cat_id int indexed
primary key will be multi-column index of both columns to enforce uniqueness
The prod_cat table is because you will inevitably end up with products they want to list in multiple categories.
It may be that you will have multiple suppliers of the same product - depends on your site. If you do then traet that the same.
IMPORTANT
The layout I have above involves a hidden danger called a CHASM TRAP: you cannot join all 3 tables, prod prod_cat cat, and expect to get accurate summary data. If you want to know how many products in a certain category have a particular price then you use the cat_id in prod_cat joined to products, so you have to look up the cat_id first.
You can handle new categories with new products in your script and with sql and the unique indexes. JUST REMEMBER, it is not a good idea to let your users create their own categories cos they will create too many instead of using existing ones - not a lot of use for your customers who don't want to have to search through a list of 50 categories for what are all realy sweat-shirts anyway.
