Data Separation Examples

@WimDecorte previously stated, “...the argument for splitting a solution up into multiple files is not solely based on UI and Data segregation. Consider backup efficiency, easy of restore, management of remote container data, and the like.”

I currently have a separate file for product images. What are some other uses of data separation you would recommend developers consider?

I am using a 3-files schema:

1 UI and business logic file
1 data file (data payload)
1 binaries file (binary payload (containers))

having a separate UI & BL file allows for modification of UI & BL without a full data migration cycle (considering that tables in data file and binaries file remain untouched.

2 Likes

We make use of model-view-controller (MVC) in our solutions and data separation is well suited to MVC. We stick to single-file solutions for small solutions. We use a three+ file approach for larger solutions:

  • 1+ files for the UI (or views);
  • 1+ files for business logic (controller);
  • 0+ files for data logic (model);
  • 1+ files for data (model).

There can be many files of the same type. We do this for modularity and code re-use. We also do this to target view files to specific environments. We sometime separate the data logic from the data. This allows us to have a pure data file which, we believe (perhaps wrongly) reduces issues when corruption hits our solutions. It does make updates easier.

We do not separate container fields from other fields. We see no need to dedicate a file for such data because we tend to use external storage for container data. I have seen comments saying people prefer separating container data regardless. Insights on reasons would be appreciated.

Hope this helps.

2 Likes

Yeah, I've used separate files for container data in the past but that was because the container data was being stored inside the FileMaker files. Now that you don't have to do that, I don't see any reason to split the container data off into a separate file.

Overall, I don't do data separation. I can, but I haven't encountered a reason to do so. It's like wiring part of your house to run on 220 volts. Or filming some of your video footage in PAL format. I know how but in the absence of a compelling reason, I'm going to keep everything under one roof and in the same box.

1 Like

We have 4 main files, and several ancillary utility files. Size is a big reason for our separation, but not the only reason. Currently our backups are 136 GB, with no container data, and grows by about a gig a week to a week and a half. We also use a development server, and a production server. When we do migrations, the data and reporting file ( which is 98% of the size ) take about an hour to migrate. The rest of the files take seconds.

UI
Data
Models/Controller
Reporting

The models/controller file is where all the CRUD stuff happens. Everything happens, as much as possible, via transactions and everything is logged in this file. We only need to store a few months worth of logs at the most, but we have planned on storing about a year's worth of logs. This makes debugging a lot easier.

As much talk is there about inconveniences with separation, I've never noticed. We also have utility files that will create fields for us, write script templates that have 80% of the work done ( inspired by Geist Interactive's karbon_generator file ).

The remaining files on our server are purpose built for specific uses. Either something specific for a department or employee, or utilities we use that we don't want in the main UI or models file. Mainly this is because they are for testing, or temporary actions we need to perform for a short-term problem or initiative.

3 Likes

It's a niche situation but for large workgroups when External Authentication is not available. In those circumstances, an opener file which carries all the unique user names and passwords, and then logins into the rest of the system under a group account. This is not even a UI file, it's jut a single point of reference for user accounts.

1 Like