Question regarding multi-file solutions development

[Lisa M.]

Hello again:

i’ve decided to re-architect Vendor Experience using a multi-file approach as follows:

-VX.fp12: Main file with all scripts, users,  credits, etc.

—vendor.fp12: vendors file with only a single vendor table

—Address.fp12: address file

— person.fp12: the person file containing a person table and a notes table (one person can have many notes)

 

my questions are as follows:

1.  Do I need to define the layouts (people, person note, vendor, address) in their respective file or can those be stored with the main file?

2.  Do I build me relationships in the sub-files (e.g. bring in the vendor table from the vendor file to link vendor ID to managing vendor ID in the person file) or should all tables have an occurrence in the relationships graph in the main file?

3.  Is there a way to cascade accounts down the chain (create them once and no matter which file is opened in FileMaker Pro/Advanced, the user must log on?

 

the reason I decided to go this route is if I decide to add more functionality in the future, I’m not trying to stuff everything into 1 database. Thus each module of the system gets its own file

[Ocean West]

There is a consideration made for separation of concerns for business logic and audience but for core features unless you hare having millions of records in each table that's when you might consider a separate file.

I do not see the need to split this set of data.

You would need to maintain logic in multiple places and recreate relationship graph as well - there you must be diligent with regard where cascade delete is enabled or you could potentially have database genocide.

In addition you will need to manually replicate and maintain credentials in all files. If this solution would be hosted then you would ideally employ external authentication and establish user accounts and credentials on the host OS.

 

 

[LaRetta]

Hi Carly,

What you describe is known as the Separation model and should only be undertaken by an advanced Developer which, since you self-rate yourself as Novice, suggests it would not be a wise design choice.  As Stephen indicates, it can greatly complicate your solution.

Can you share your reasoning for splitting into multiple files?  Maybe there are better ways of solving those issues instead.  🙂

[Lisa M.]

4 hours ago, LaRetta said:

Hi Carly,

What you describe is known as the Separation model and should only be undertaken by an advanced Developer which, since you self-rate yourself as Novice, suggests it would not be a wise design choice.  As Stephen indicates, it can greatly complicate your solution.

Can you share your reasoning for splitting into multiple files?  Maybe there are better ways of solving those issues instead.  🙂

to give a short answer: one file = one broad class of data (companies, people, vendors, cases, etc.).

 

the more detailed answer: (1) If I want to extend any of the broad class definitions (e.g. add “notes” to cases) just extend one module rather than having Notes.Cases, Notes.People, Notes.Companies, etc. all cluttering lists, relationships graph, and getting very confused. If I want to extend an extension (again using notes as an example adding “attached files” to a note for example) it’s only valid for that occurrence of notes (it might make sense to have “attached files” in say a customer support notes module (For things like attached PDF documentation), but not in the notes for a person where things like abusive customer warnings would go. (2) By keeping “system” and “user” data separate, if the user is doing regular backups (which they should be) and only cares about *their* data and not things like user accounts, preferences, etc.  they can reload from scratch, drop in their backup files, and re-configure… like it never even happened  (3) was having some issues in scripting a fallback OnLastWindowClose (Original Idea: everything in one file possibly multiple windows, if the user closes the launchpad (with all the buttons to do things, it should re-spawn unless the user explicitly does something else to close the application (accidentally created an endless loop doing that).  As opposed to new idea: have all the front-end layouts, developer credits, about screen, help, preferences, accounts/privileges, etc. in a separate file distinct from actual data files thus it acts as a single front-end and the user never really sees behind the curtain (unless i can call layouts from external files)). Thus, if user closes it… they meant to close it. (4) I’ve seen it done a few times and wanted to “try a stupid idea that’s probably more trouble than it’s worth…” since I’m not distributing my work right now… why not move fast and break… uh, (things?)… yes, “things” is the right word that goes on the end of that sentence….

 

the only way to get better is to learn by doing, learn by trying new things, etc.  for awhile (when i first started out), I wasn’t even touching scripting (looked daunting and my attitude was “Who needs scripts?  Everyone who runs this is going to have FileMaker, have a mouse and keyboard, and be proficient with it… fast-forward to now and I’m trying to push scripts to some weird places)  back in the day… now that i’ve got a few scripts under my belt, while not perfect or very good… I’m getting better and more confident with that capability

 

hope this explanation helps

Edited September 22, 2021 by Carly F.
Fixed spelling/autocorrect errors to make post more readable

[Ocean West]

if you have the time and patience and plenty of backups you can try multiple files make a sand box of files and link them with the most basic connections and quickly you will see how hard it is to manage that many files. 

I have a customer that has over 125 files - yes FILES. This is a legacy solution that started back in the v6 days or earlier. The reason so many files - back then a 1 Table = 1 File. there have been efforts to migrate and consolidate data but it is not with out a lot of patience and work. And since it's working right now and running the business great car must be made when working on the system its like changing the car tire while we are driving 80 down the freeway. There are challenges. and I wouldn't recommend starting out in this manner. 

I do have other solutions where the core of all logic resides in an interface file and you can maintain set of data tables based on context such as Attachments - although its not necessary as much these days because attachments I don't store internally to the file but externally on the server. I do have some files for logs or other data warehouse where there millions of records narrow and deep with little in way of other calculations or summary schemas. 

*clutter* seemingly can be mitigated by a well maintained naming convention and organization skills. If you're considering a data model such as Anchor Buoy or Spider etc these each have their pro's and cons but most developers will have a variation of each, and it's knowing when to break the rules to provide desired results. If you try to plan out the A/B method first you just might end up with table occurrences that are not even touched just because you 'think' you may need them in the future for a lookup or such.

From what you mention your profile and other threads you are not developing in a current version of FileMaker, which has provide much more wider array of tools to build a solid solution on.

Button Bars, Pop Over Buttons , Slide Panels, JSON, Card Windows. etc.