7 Replies Latest reply on Apr 29, 2012 6:00 AM by beverly

    Base question about Anchor Buoy Structure

    brianquillin

      Quick question about the A/B method:

       

      Why are separate tables used for Addresses, Phones, Emails, etc in many of the existing examples?

       

      Why would a single Attributes table not suffice for collecting those in one table?

       

      (I guess at that point I'm nearly back to collecting all that information into a Person or Company table like I have done before.)

       

      Forgive the simplicity of the question, I'm working to learn this methodology and I want to understand the rationale behind segmenting these items.

       

      Thanks in advance...

        • 1. Re: Base question about Anchor Buoy Structure
          DavidJondreau

          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.

          • 2. Re: Base question about Anchor Buoy Structure
            brianquillin

            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.?

             

            Thanks again....

            • 3. Re: Base question about Anchor Buoy Structure
              ibrahim_bittar

              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.

               

              Regards

               

              Ibrahim

              • 4. Re: Base question about Anchor Buoy Structure
                brianquillin

                I think that's where I'm headed.  It seemed like overkill to store that info in a separate tables.

                 

                Thanks...

                • 5. Re: Base question about Anchor Buoy Structure
                  beverly

                  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

                  • 6. Re: Base question about Anchor Buoy Structure
                    Vaughan

                    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?

                     

                    Thanks.

                    • 7. Re: Base question about Anchor Buoy Structure
                      beverly

                      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

                       

                      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?

                       

                      Thanks.