Advice on best design approach

[Spidey3721]

Fundamental approach question :

I am putting together a database to track owner selections for condominium
buildings. I intend to be tracking many hundreds of different owners in the
coming years (UnitID), for many different building projects (ProjectID).

For each Owner (UnitID) - I expect to be tracking approx 50 different
"Selections" (Examples: Living room floor, Living room paint, Living rooom
crown Molding (Y/N), Kitchen microwave, Stove, Light fixture, Master bath
vanity type, Master bath Light fixture, Master bath floor, etc, etc, etc....

Question: Does it make more sense in the long run to have each of those
selection categories as separate FIELDS in a selection table (Each record
would have a ProjectID field, UnitID Field, Living room FloorID field,
Living Room PaintID field, etc....)

OR: Should I have a table that includes a ProjectID field, UnitID Field, a
CategoryID field (Living Room, Master bath, etc...), a SubcategoryID field
(Floortype, paint, vanity wood, etc, etc...).

I'm stuck between the two when I think of my form design for the two
different approaches. My gut tells me that the second approach is best, but
I want to be able to add new Projects/Units easily (I could just add a
record with the First approach and fill in control text boxes for each of
the MANY fields.)

 

[Douglas J. Steele]

It is a bad idea to have each of the selection categories as a separate
field. Not only does it make it difficult to add additional categories in
the future, but a lot of the SQL will be much more difficult. (It also
violates database normalization principles)