file setup discussion/recommendations

[Jodin]

I'm in the conceptual stages on a new project that will ultimately be a vertical market app deployed to hundreds of sites. This is an upgrade from an existing solution done in fmp5.5 that entailed over 30 files.

The million dollar question seems to be how best to set up your file structure. So much flexibility is now available for us that we can put our tables almost anywhere, so now the big question is how best to make the file structure chosen give you the features you want without adding more development complexity than is needed.

In my eyes the true value of a proper data separation model is the portability of the non-data files (interface, logic, utilities, etc.). Import-less upgrades are a pretty nice thing and multiple interface files into one data file is extremely powerful. Any other benefits seem to be trivial or at best academic in our situation. Either way a smart solution will be backing itself up and perhaps archiving off-site, and we include a file utility to fix damage, so the concept of the 'safe' data file is not as intriguing to me.

With this thinking I'm currently leaning towards a 3-file system: GUI, Data, and Utility. Utility will start and shut down the system, ensuring security, file integrity and proper backups, and be able to recover damaged files before opening. Data will hold all of the user-entered data and be *mostly* flat data (more on that below). GUI will hold most of the logic, print the reports, provide the GUI, and appear to 'be' the program to the user.

This is not a true separation model because there will be some calcs and scripts in the Data file. These of course could require debugging or modification down the road so a new version of the data file would need to be swapped in prior to an import. But given some good QA and a slate of extra fields in each table in Data hopefully a new Data file won't need to sent out often.

The Utilities file starts and shuts down the system, does backups and archives, and file repairs. That's it, there's not much more to it.

The GUI file is where the obscene relationship diagram and the packed scriptmaker lives. I foresee many fields in this file, but all will be session-data internal to the program and used for operation. User-entered data particular to the use of the application will not be stored in GUI.

The next step up in the separation ladder seems to be having a 'shadow' table that holds business logic (calcs, scripts, etc) but mirrors exactly the actual data table. This seems terribly redundant to me if this is the only way to achieve this. To keep 2 massive data files synced during development will basically double the work unless you have a rock solid spec to develop from. And I want to see someone develop a new product on a new platform with limited time that has a rock solid spec!

Anyway, thanks for reading and please give your opinions on my idea. I'm not sold on this being the best way yet but I think that I'm not totally convinced that doing a true separation in FM7 is cost and time effective for us.