Contacts and Companies in SeedCode Complete

General Information about upcoming products, upgrades, etc.
Posts: 21
Joined: Thu Feb 04, 2010 6:26 pm
PostPosted: Wed Jun 13, 2012 8:15 am
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~
Debi Rubel
FullCity Consulting
SeedCode Staff
SeedCode Staff
Posts: 691
Joined: Mon Feb 28, 2011 2:47 pm
PostPosted: Wed Jun 13, 2012 8:42 am
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 8)

hth and would love to hear anybody else's thoughts (flames)
-Jason
Posts: 21
Joined: Thu Feb 04, 2010 6:26 pm
PostPosted: Wed Jun 13, 2012 10:20 am
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~
Debi Rubel
FullCity Consulting

Return to FileMaker Products (General)

Who is online

Users browsing this forum: No registered users and 2 guests

cron
(855) SEEDCODE
[email protected]
Follow us: