>Hi,
>Thank you for your information. Hmm,.. according to the sample data in >previous message, it seem like you cant diffrentiate the modal of item?
Each different item is a class, I'm using a very generic example, I can have a class for every different type of pant thhere is, that's what I do, of course you can clasify as much as you want, this is enough in my case but you might want to have all pants be of a common class and then differentiate the model, brand or whatever. Maybe I should call it model id now that I think about it.
This is more similiar to what I actually have:
Code ClassID Class Color Size Stock
PANT1 1 DENIM PANTS NAVY 32X32 100
PANT2 2 WORK PANTS KHAKY 32X32 55
Again, I include the descriptions for clarity, I only have numeric id's in my items table for class, color and size.
Each "class" has a code, that's what I use to make a distinction between items. As you may have noticed there is nothing truly binding the different type of pants, it wasn't required in this system, it could be useful but it would make data entry more complicated when the items are registered for the first time.
You could easily use the same principle and have an items table like this
Item ID - A unique identifier, this would be you Primary Key
Class ID - You'd have one for pants, one for shirts, etc
Model ID - Here you would differentiate between pants for example, or you could instead use a code or part number here. I handle multiple codes, so this doesn't work for me.
Brand ID - Manufacturer
Color ID
Size ID
It all depends on what you need, also keep in mind that whenever you need all the information for a given item you'll have to pull it from all the different tables, that is, to present the user with something meaningful you'll have to link the items table to the classes, colors, sizes, models, and brands table, to pull the actual descriptions, since you'll only have numeric id's in your items table, you can do this through table relations or views, it's just more work than with a flat items table.
HTH
