Understanding Response

[Bill]

Hi John,

Wow, that's a head full. I think I get it though. Most of
your assumptions are correct and I can see the future
challenges you point out using methods 1) and 2) you
mention.

Solution 3) seems the most appropriate. Let me summarize
in my own words to ensure I get the gest of your solution.

Rather than have a seperate table for each category of
product, have a single product table with all products we
stock in a single table identified by a productID field.
The record count of this table would equal the number of
items in inventory.

A seperate attribute table (attribute list) which would
store every possible attribute for each product (this
could have over onehundred records). The record count of
this table would equal the number of categorys * the
number of attributes for each category.

A Products attribute table which would relate the
individual product to it's particular attribute. The
record count in this table would equal the number of items
in inventory * the number of categories * the number of
attributes for each category.

Do I understand correctly?

So this thread will now be found in the new group you
cited?

While you are being so helpful, could you please address
the question I posted 5/4/04 12:23 "Working directory"?

Thanks for the help. It was very insightful.

Bill

 

[John Nurick]

Hi Bill,

Comments inline.

Hi John,

Wow, that's a head full. I think I get it though. Most of
your assumptions are correct and I can see the future
challenges you point out using methods 1) and 2) you
mention.

Solution 3) seems the most appropriate. Let me summarize
in my own words to ensure I get the gest of your solution.

Rather than have a seperate table for each category of
product, have a single product table with all products we
stock in a single table identified by a productID field.
The record count of this table would equal the number of
items in inventory.

I'm never quite certain of the terminology. If you offer 250 different
kinds of ball bearings, there'd be one record in the table for each
kind. If you want the database to track the number of each you have in
stock, that's a separate task.

A seperate attribute table (attribute list) which would
store every possible attribute for each product (this
could have over onehundred records). The record count of
this table would equal the number of categorys * the
number of attributes for each category.

Probably. On consideration you may decide you need one table for all the
different attributes (e.g. length, height, width, voltage, amperage,
power factor...) regardless of category, and a second that tracks which
attributes are relevant to each category (i.e. a many-to-many
relationship between attributes and categories).

A Products attribute table which would relate the
individual product to it's particular attribute. The
record count in this table would equal the number of items
in inventory * the number of categories * the number of
attributes for each category.

That sounds right. For those ball bearings, the attributes would be
things like
Outside Diameter (mm)
Inside Diameter (mm)
Width (mm)
Sealed (yes/no)
Type (standard, double row, self-aligning...)

Don't worry if this means you're looking at 50,000 or 100,000 records:
provided the fields you need to query on are indexed this won't worry
Access at all.

Do I understand correctly?

So this thread will now be found in the new group you
cited?

Your original thread "Moving data from popup to subform" can now be
found in microsoft.public.access.tablesdbdesign. This message is in a
separate thread, but I've crossposted it there too.