I'm customizing SeedCode Complete 3.11 in FMP 12 for a client that is currently using a customized previous version of the older software. The old version uses contacts, with an option to set the contact as a company; the new version separates the company and contact tables.

I've been flip-flopping about whether to maintain that separation, or treat contacts using a "type," as was done previously.

Advantages of maintaining separation:
* That's the way of the newest SC Complete.

Advantages of maintaining single combined table:
* Simplify import when it comes time for that.
* Maintain client's current methodology for some existing customization. I can't think of a specific example off-hand, but I expect I'll run into this as I get into some of the financial modules.
* Selection of related data from single source. This is one of the biggest issues: for example, when picking a medical support service for a patient, we may want to pick a pharmacy or a pharmacist, a medical center or a specific MD -- no need to worry about which table the child data comes from.

Coming to a crossroads where we need to finalize a decision soon.
Any suggestions?
Any gotchas to watch out for with either scenario?
Anything else I'm forgetting to consider?
Anybody else out there already have experience with this?

TIA,
d~

Hey Debi,

I think this is a classic db/FileMaker question, and I'm not sure there's a "right" answer here.

It's certainly not uncommon for us to "pull" companies when we do a custom job and that's one of the reasons we make companies so light.

For us, I think the main considerations are functionality, i.e. can companies and contacts do the same thing. An example is working with builders, where the Architect is as likely to be an individual as they are a firm, so having them in the table with a flag marking them as one type or the other makes sense, and also makes our lives as developers easier.

I think the biggest gotcha can come from having to deal with two tables if a related entity can be either. If I had to do a report to evaluate the architects I've worked with then having to do this on one table is certainly easier, also the selectors we use for assigning these folks to Projects, etc. is easier with a single table as well.

Again, not sure there's a right answer here, but there's 2 cents worth

hth and would love to hear anybody else's thoughts (flames)
-Jason

Jason,

Thanks, this does help: I needed to make sure I wasn't going down a slippery slope!

Still curious to hear if anyone else has experience and/or suggestions,
d~