One database or several for Contact Info

[HawkLA]

I am trying to set up a Contact database for my business. I have about 4 different types of clients. Should I make 4 different databases or Make one?

Everyone has address and contact info, but each group has different calulated fields and additional information fields.

Each group does not relate to the other. I want to target my marketing differently for the groups.

What are the pros and cons of seperating the databases? Could I make a different form to fill out for each group type and use the same database? What should I do?

HawkLA

[Søren Dyhr]

What are the pros and cons of seperating the databases?

But don't they share a fair share of equal attributes? I vote for one single with the addition of a type attribute! slicing and dicing in each type is very easy ...dare I say business as usual.

--sd

[HawkLA]

Ok. So I make a Type Attribute field. What do you mean about slicing and dicing for each type? If I select one type, would the data entry screen change for each type? I just need a little more info to get me started.

Thanks!

HawkLA

[beatryder]

I had a similar situation, but instead of contacts I had components/sub-assemblies/parts. They all contained the same information except for their "type".

I was advised to keep them in the same table, and then when you display them in a layout to perform a sort (or find) to show only the ones with the correct type. So following this train of thought, I think it would be best for you to keep all contacts in one table, and just sort them based on "type".

You can take a look at my data base to get an idea of how I organized mine.

--Dawn

PDS-MAFC250-V5-0-StrippedPlay.zip

[LaRetta]

...but each group has different calulated fields and additional information fields.

I use 3 self-join portals. We have Retail customers, Wholesale customers and Associates all within same Contacts table. When the TYPE is filled in, the appropriate fields (that ONLY apply to THAT contact type) will display. In this way, staff doesn't waste time entering data on Associate type in fields only designed for wholesale customers. Fields in common remain on the main layout but specialty fields display/disappear as needed. If you would like assistance on how to do this, let us know.

LaRetta

[HawkLA]

This is exactly what I need to do! Could you give me a little instruction on how to do this? How do you get the data entry screen to change when you pick a customer type? That would be perfect so that the data entry person would only see the fields that are associated with that type of customer.

Thanks!!!

HawkLA

[beatryder]

Have you taken a look at the example I posted for you?

I've got a different layout for each "type", which has different fields displayed. When you click the button to go to, in my case Components, it triggers a script which takes you to the correct layout and performs a find based on type.

Poke around in my example, hopefully it will help you.

--Dawn

[HawkLA]

I just looked at your sample database. When I click on the buttons on the right, it changes the layout that you are working with in the layouts menu. That is very nice, and I think that would work well for me. Now I just need to figure out how to make those buttons work on my database to change the forms! Any tips? I don't know anything about scripting.

HawkLA

[LaRetta]

Hi HawkLA,

This is called invisible portal and is technique you can search here on Forums and produce a LOT better examples. But it was quicker for me to give example than search for them. The idea is to establish a relationship to the same table when you select Customer Type which displays the same fields as the same record (note the uniqueID is also included in the same TO - but restricts the fields (hides them) when Customer Type is NOT (in attached example), a Business. Two records ... first is individual and second is Business.

There are many other ways to achieve this effect but it saves having different layouts. Its drawback is that the same fields (some for individuals and some for customers) can't occupy the same space (unless you go to more advanced dynamic techniques). But you CAN display calculations over portal space if you make the field large enough to reside outside the portal on top and left side (just include a condition looking for 'related records' and display only when no relationship so you don't have calcs over displaying fields). I use this technique when I have a handful of fields which shouldn't display for Individuals but should for Businesses. Note that I also script it so I can add a Commit Record/Request (I've turned off allow entry in Browse) otherwise it wouldn't display/hide until User exited the Type field. Also, unclick 'show field frames' in layout setup. This technique also works for printing forms.

Only you can decide which techniques to use in various places; none are good and none are bad; this is why FileMaker is so darned much fun. :wink2:

MultiTypeCustomers.zip