I segment Phone, Email, Address into separate tables because it makes implementing functions for users a trazillion times easier.
Are you asking why not put all contact info table into a Person or Company table or why not have one table to collect all types of Contact Info table?
If it's the former...well, I can think of a bunch of scenarios where that would be frustrating...like people or companies with 2 or 6 e-mail addresses? Then you need 5 additional fields (or a repeater). That's really annoying to deal with. Downloading a list of all the e-mail address to upload to MailChimp with that set-up sucks. And what if some e-mail addresses are ok to send a blast to or others aren't? I'd want to mark each address with a "Don't send marketing e-mail". That's an additional 6 fields. And then some yahoo is going to have seven e-mail addresses. Ugh.
If it's the latter...would you have Street, City, State, Zip, Phone, Email, fields in each record with only one of those types being filled out? That doesn't seem efficient.
But this question isn't strictly an A/B question. A/B is just a method for organizing your table occurences, not a method for determining which tables you should have.
Thanks for the reply...
I was actually asking both of those questions.
My previous (and first) solutions all collected base information for Contacts and in that Contacts table I collected their contact information. But as my understanding of FMP grows and I see different methods of capturing info, I am still trying to grasp the best method for me to use.
I've seen a sample solution built with all contact info (address lines, phones, emails) being collected in one Attributes table. In that example, a Person's contact info was entered into global fields that were then stored in the Attributes table (which seemingly eliminated many TOs by using filtered portals based on the type of the Attributes table).
I'm starting to redesign one of my bigger FMP 11 solutions (for my skill level) and I've decieded to go from the ground up (I need the practice). At this point, I'm thinking of going with the more traditional (I assume) approach of using separate tables for Addresses, Phones, and Emails. (If so, does that mean that I'll need a TO for every 'type' of information; business, home, cell, personal, direct line, etc.?
In my case, because a contact can have many addresses and an address can have many phones, emails and so on.
Basically I use three tables: contacts, addresses and comms. In comms I store phone numbers, websites and emails.
I think that's where I'm headed. It seemed like overkill to store that info in a separate tables.
Brian, I don't separate email and phones. It's all COMM (communication) and can include web urls as well as email and phones.
I do separate addresses (which can include GPS locations, not just postal addresses).
I also separate people and entities.
People (and other entities such as groups and schools and companies) can all have COMM and ADDR that varies, so yes I have separate tables for these. Although, a human generally is the target of COMM and items ADDR'd, they can be generic items.
This is NOT overkill if you have to have multiple ways to reach people and entities. If your design is simple (one phone, one address - and WHO has that these days?!), then keep them in the same table.
Beverly: how do you manange sending e-mail to people? Does one get marked as "primary" or does a message get sent to all a person's e-mail?
Yes, one gets marked as primary (same with the phones). And you can provide the option to email to "all" or just the primary. On some layouts, I have a button (or a drop-down list) to send email to and you manually select which one.
Beverly: how do you the manange sending e-mail to people? Does one get marked as "primary" or does a message get sent to all a person's e-mail?