Too many fields?

[LJ]

Hi,

I'm creating a database to track prospects and buyers of
houses being built. I need to tract prospect info,
house/model info, and buyer info. So my basic table
structure is something like this:

Prospects: ProspID*, Name, Add, etc.
Models: ModelLot*, Code, Style, Price, ect.
Buyers: BID*, ProspID, ModelLot, CloseInfo, MortgInfo,
ColorSelections

Here's my first question: If I put all the info about
buyers into one table, I have 120 fields. This is
normalized - no repetition, no many to one scenarios. I
could seperate the info into several tables with a 1-1
relationship (Mortgage Info could have its own table and
Color Selection (for floors, bathroom fixtures, etc.)
could have its own table. Would it be better to keep one
table or split the data up?

Second: In addition to these 120 fields, I will need to
create 20 or so calculations. These fields will later be
used in a document merged to Word. (The doc is about 20
pages and will be easier for other people to edit in
word.) I suppose I can create the fields and do the
calculations in a query and then base my form on that, and
also use the query for the mail merge. Is there a better
way? I don't really want to create fields in a table to
store the calcuations...

Any help would be most appreciated.

LJ

 

[Tim Ferguson]

If I put all the info about
buyers into one table, I have 120 fields. This is
normalized

Don't believe it. Twenty is large, fifty or sixty is a once-in-a-lifetime
job.

Tim F