I don't understand this point i thought you would have better wanted to avoid duplicates
You want to avoid duplicates in the database if practical. This is handled by the database normalisation process. On the shop system I wrote the product name and short description were not normalised in the database. This was partly due to legacy reasons and partly due to a design decision. If the user changed a product name we wanted only that product name to change and not have to worry about checking if the user wanted all the corresponding entries to change.. It was complicated enough with a translation db join.
For a shop system I would design it for the shop owner requirements and needs.
Lol....the shop owner hasnt a clue as to wat she want other than she want to seel stuff. So i am trying to give her a bit more "flexibility" and options
what did u mean the minimum and maximum column???
Ah now this gets a bit more complicated and it is probably not needed for your system.
Pens - You have pakets of 10, 20 and 30 pens and also sell them singly (you rip open a 30 pack).
Example 1 - People have the option of buying each packet separately. No problem
Example 2 - System determines paket sizes automatically based on quantity you want to buy 35 = 1 box 10, one box 20 and 5 single.
Example 3 - People get a reduction for buying a pack of 20 rather than 20 single items but can insist on 20 single if they want to.
Example 4 - People get penalized for buying the larger packs although you cannot buy more than 10 singly.
Ok fairly simplistic example, with min and max columns, you can create various combinations. They correspond to the possible purchase quantity.