getting organized

[shank]

I need to design a table for product attributes that seem to go on forever.
Basically, we're trying to get all the possible responses that could ever be
asked about the product into a table. I just grabbed a bunch of the
questions and cut-n-pasted below to give you an idea how these questions can
go on forever.

The big question is how you would name the [fields] and keep track of what's
what? There could easily be 200 questions. Would you just name the fields a,
b, c, d, e, f, etc. and at the same time build a form and map fields
directly to questions? Then I would think it'd be a nightmare to build a
report. Any suggestions?
thanks!


Approximate assembly time?
Are batteries included with item?
BTB Net Cost:
Can item be wrapped w/o gift box?
Case Pack Quantity:
Case Pack Quantity:
Co-Op for Placement in Catalog ($):
Cubic meters per Master pack:
Discount Catalog Allowance (%):
Discount Defective Allowance (Max 2%):
Discount Freight Allowance (%):
Do you carry liability insurance?
Does item require batteries?
Does item ship as an assortment?
Dollar Limit for Free Freight Allowance:
Early Payment (2% net 30):
First introduced by any company
FOB
Harmonize Code:
If "Yes" above, is item identical to last year?
If Case Pack is One, is there a Picture on Box?
If Item is a Ride-on what are size restrictions?
If Item is a Ride-on what is maximum capacity?
If item is selected for cover or back cover of catalog do you agree to
$400.00 Co-op Charge?
If so, what kind of batteries?
Initial PO Lead Time (Days):
Is item personalized?
Is Item Under 84"? (for FedEx)
Is Item Under 130"? (for FedEx)
Is liability insurance $1M or more?
Is Product an Award Winner?
Is Single Box FedEx Shippable? (minimum 200 lbs. corrugated)
Item made of what primary material?
Lead time from PO to shipment:
List cost:
Master Pack Quantity:
Master Pack Quantity:
Masters packs per 40' Container:
Minimum Order Amount:
Number of characters for pz:
Point of Shipping Origin (State):
Product Availability Date:
Reorder PO Lead Time (Days):
Specifications #1
Specifications #2
Suggested Retail:
Terms (Net 60 days):
Units per 40' Container:
Volume YE Allowance:
Was item featured by BTB last year?
What are wheel(s) made of?
What country is item made in?
What is the measurement from pedal to seat?
What is the measurement from seat to ground?
Wheel dimensions? (if applicable)
Will you add BTBT as an additional insured for three years from this order?
Year item was first introduced in the U.S.?

 

[John Vinson]

The big question is how you would name the [fields] and keep track of what's
what? There could easily be 200 questions. Would you just name the fields a,
b, c, d, e, f, etc. and at the same time build a form and map fields
directly to questions? Then I would think it'd be a nightmare to build a
report. Any suggestions?

Yes. Don't do it this way!

"Fields are expensive, records are cheap". Each question should be a
different *RECORD* in a table, not a new field.

See
http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='At Your Survey 2000'
for an example of how this database could be set up.

John W. Vinson[MVP]

 

[Jamie Collins]

"Fields are expensive, records are cheap". Each question should be a
different *RECORD* in a table, not a new field.

All the OP's questions appear to be attributes (the OP said as much),
so arguably they are best as 'fields' rather than 'records'.

However, I don't think they are all from the same domain; contrast 'Do
you carry liability insurance?' with 'What is the measurement from
pedal to seat?' (it sounds like a gag: 'What has a pedal and a seat,
and carries liability insurance?' A rick-not-so-sure ;-) Therefore, I
would expect more than one table when implemented. Am I saying to the
OP, 'Learn normalization'? Actually, I think I'm saying, 'Learn data
modelling: entities, attributes, relationships, etc'.

Jamie.

--

 

[shank]

All the OP's questions appear to be attributes (the OP said as much),
so arguably they are best as 'fields' rather than 'records'.

However, I don't think they are all from the same domain; contrast 'Do
you carry liability insurance?' with 'What is the measurement from
pedal to seat?' (it sounds like a gag: 'What has a pedal and a seat,
and carries liability insurance?' A rick-not-so-sure ;-) Therefore, I
would expect more than one table when implemented. Am I saying to the
OP, 'Learn normalization'? Actually, I think I'm saying, 'Learn data
modelling: entities, attributes, relationships, etc'.

Jamie.

= = = = = = = = = = = = = = = = = =
John's idea is the best way and that's they way we're going. None of this
was a gag. I just cut-n-pasted sample questions from vendor forms. The
questions are authentic and there's hundreds of them that need to be
responded too for each product. Welcome to the world of retail!

 

[Jamie Collins]

The
questions are authentic and there's hundreds of them that need to be
responded too for each product.

Ah, so the questions *are* questions. My bad.

Jamie.

--