table design

Results 1 to 2 of 2

Thread: table design

  1. #1
    Join Date
    Dec 1969

    Default table design

    I am using access for a database and am wonde4ring what the best approach is to the design. Currently we have 1900 records, which i feel could be reduced substantially, for instance<BR><BR>product1 comes in 5 strengths and currently it is like the following<BR><BR>prod1 str1<BR>prod1 str2<BR>prod1 str3 and so on...<BR><BR>would it not be best to put the strengths of the product in a seperate table and call them based on the productID?<BR><BR>Table 1<BR>productID<BR>categoryID<BR>etc...<BR><BR>Tabl e 2<BR>StrenthID<BR>productID<BR>etc...<BR><BR>Than x

  2. #2
    Join Date
    Dec 1969

    Default That's not enough

    If the strengths have common names, common characteristics, etc., then yes, you should have a STRENGTHS table.<BR><BR>But then you need a third table that does nothing but link the Strengths to the product. You might also put the price in that table.<BR><BR>PRODUCTS<BR> pid - pname<BR> 1 - widget<BR> 2 - frample<BR><BR>STRENGTHS<BR> sid - sname<BR> 1 - wimpy<BR> 2 - flab<BR> 3 - buff<BR><BR>ProductStrengths<BR> pid - sid - price<BR> 1 - 1 - 1.98<BR> 1 - 2 - 3.95<BR> 1 - 3 - 5.75<BR> 2 - 2 - 9.95<BR><BR>But if you can&#039;t use the same STRENGTHS table entries for more than one product (if they are too specialized for that), then you should just stick with the single table.<BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts