Appointments and Types, Events and Sources

General Information about upcoming products, upgrades, etc.
Posts: 21
Joined: Thu Feb 04, 2010 6:26 pm
PostPosted: Wed Jun 13, 2012 4:01 pm
OK - Keeping with the theme of bringing a client to SeedCode Complete 3.11 in FMP 12 from their use of a customized previous version of the older software.

If I understand correctly, the old version used Appointments (base) and it TOs to show what are now called Events.

In the older system, many different types of appointments could be accommodated by adding their entity-specific fields to the Appointments table. So a training session might use the standard Appointments fields to include a course/event name, date, time, etc., and then the developer could add separate fields for "previous course requirements" and "grade." Or, a social incident could use standard fields, but add "seriousness" and "reported to" fields to the Appointments table to log that data. Ultimately, different kinds of incidents could be handled in one table, and filtered by "type" (ApptType_kf), which was also used to color-code the appointments.

In the new system, it seems that the Sources mapping provides for different "types" of events, for filtering and (optionally) for color-coding. We've already moved many fields from the old Appointments table to the new Events table, but as I progress, I'm wondering if that's the best way. For some items, for instance, it could be nice to show them in the navigation bar, have special form and list layouts, etc., even though I know it would mean finding sub-sets of data and importing them separately when it's time for that. Separate tables may also make it easier to manage varying numbers of contact links (e.g., an appointment event may just need a single contact, or a second "appointment WITH" contact key; whereas a training may involve multiple teachers AND multiple students), but I'm not sure.

Question 1: Am I understanding all this correctly?

Question(s) 2: What are the advantages and disadvantages of incorporating these different types of data into events, versus creating separate tables for them? Is there a "key deciding factor" to go in one direction versus the other - for a given table, or for the solution overall? Any gotchas to watch out for?

TIA,
d~
Debi Rubel
FullCity Consulting
SeedCode Staff
SeedCode Staff
Posts: 691
Joined: Mon Feb 28, 2011 2:47 pm
PostPosted: Thu Jun 14, 2012 12:28 pm
Hi Debi,

Thanks for posting this, good stuff!

Right, you're understanding this correctly.

With 3.11 I think you're really better off keeping them in one table with flags rather than going to multiple sources/tables. Performance does take a hit with multiple sources, as we need to perform finds for each source and then sort all the combined results. Adding fields to tables can affect performance as well, particularly over the WAN, but I think that you'll take a bigger hit with the sources.

Additionally, there's a lot of additional abstraction that will need to be added to the scripts to have each source behave the same with repeating events, etc.

hth,
Jason
Posts: 21
Joined: Thu Feb 04, 2010 6:26 pm
PostPosted: Fri Jun 15, 2012 5:53 am
Jason - Thanks for your ongoing advice and help! d~
Debi Rubel
FullCity Consulting
SeedCode Staff
SeedCode Staff
Posts: 691
Joined: Mon Feb 28, 2011 2:47 pm
PostPosted: Fri Jun 15, 2012 4:48 pm
You got it Debi 8)
and thank you for posting this great stuff here!

Return to FileMaker Products (General)

Who is online

Users browsing this forum: No registered users and 3 guests

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