F
Fred
I know what Outlook is, I just stopped using it (and switched to free
Thunderbird) a long time ago. It has the one big problem where it sends
attachments out as unreadable-by-many .dat files unless you use "plain text"
compose mode. I just meant that since I don't use it I don't know it's
screens etc.
- - - -
However, I'm assuming that, for a contact, Outlook has a handful of
standardized types of phone numbers, and thus a pre-defined heading for each
of them. If that is what you want and can live with, then you'd skip this
entire thread, and go back to a single table with a field for each phone
number type.
Under the structure that the respondents in this thread came up with, you
have no such predetermined structure / restructions. If one person has 15
phone numbers, many of non-standard types, their record would have 15. If
someone else had only one, their list would have only one.
One other possibility would be to automate it so that when you enter a new
person, it automatically loads a set of records in the phone number table for
the common types. So you'd have titles and blanks for the common phone
number types, plus the ability to add others. This would be a lot of work
and complexity to go though, resulting in what many would call bad data.
In my opinion, make the leap, and go with your #3, which is how it's
normally done when databasing things such as yours. It does not have the
restriction/problem that you describe....it lets you put an unlimited number
of phone numbers under each person, indluding repition of the types, if you
so choose.
Thunderbird) a long time ago. It has the one big problem where it sends
attachments out as unreadable-by-many .dat files unless you use "plain text"
compose mode. I just meant that since I don't use it I don't know it's
screens etc.
- - - -
However, I'm assuming that, for a contact, Outlook has a handful of
standardized types of phone numbers, and thus a pre-defined heading for each
of them. If that is what you want and can live with, then you'd skip this
entire thread, and go back to a single table with a field for each phone
number type.
Under the structure that the respondents in this thread came up with, you
have no such predetermined structure / restructions. If one person has 15
phone numbers, many of non-standard types, their record would have 15. If
someone else had only one, their list would have only one.
One other possibility would be to automate it so that when you enter a new
person, it automatically loads a set of records in the phone number table for
the common types. So you'd have titles and blanks for the common phone
number types, plus the ability to add others. This would be a lot of work
and complexity to go though, resulting in what many would call bad data.
In my opinion, make the leap, and go with your #3, which is how it's
normally done when databasing things such as yours. It does not have the
restriction/problem that you describe....it lets you put an unlimited number
of phone numbers under each person, indluding repition of the types, if you
so choose.
