Separation Model: Calculated FIelds

[T-Square]

Perhaps this note should go into the Left Brain forum, but ...

I've been working with a Separation Model (SM) app for almost a year now, and I am currently re-examining it from the perspective of managing changes in the backend datafile.

As has been noted recently in other threads here, the advantages of the SM apparently lessen if the need to change the back end data structure happens very often. Going back further, there were threads that discussed separating data, interface, and business rules (BR) into three elements.

In my situation, I chose not to apply the BR portion of the model, since:

a) it seemed like it would require substantial re-thinking of the ways that I was accomplishing my goals, specifically with regard to relationships built on calc fields (I suspect now that this might not be the case), and

I didn't like the idea of duplicating the data file, which was how I understood the BR extension to work.

The model I have ended up with is as follows:

1) Back end data file with tables housing Real Data fields, calculation fields, and legacy global fields (see below). This file contains a few housekeeping scripts (an Open script and some data importing scripts), and one basic layout for each table (to enable import/export). Included in this table is a Client Configuration table for handling installation-wide settings.

2) An interface file that contains all user layouts, tables for Application Settings (Developer info, app version, etc.), system help, and global fields (created to eventually supplant backend file globals), and all interface scripts.

3) A Reports file that contains layouts for printed reports and scripts to manage these reports. The reason I created a reports file separate from the interface file is that I wanted to be able to distribute a locked-down interface while still giving my clients the ability to create or modify their reports as they needed.

At this time, I am considering moving all the calculation fields "forward" into the interface file, by creating a Calcs table in the interface and linking it to the relationships graph through my Globals table.

The prospect of moving these fields is daunting, but it would help stabilize the backend file substantially if it could be done.

I think this will work in my particular situation since my Relationships Graph is completely interconnected, making every TO visible to Calc table. My question to put out there is this: has anyone else tried specifically doing this, and if so, what suggestions or helpful tips might you make?

One thing I think might be an issue is whether I would need to connect the Calcs table off of every TO that needs a calculation, or whether I could simply set the calculation context to the appropriate TO. Another issue will be to determine a naming scheme that would be clear and efficient, since calculations for all data tables would co-reside in one table.

Yet another issue will be to figure out how best to eliminate the use of calculations in structural areas such as relationships. On the face of it, it would seem to me that it should be possible to eliminate all uses of calculated fields in relationships, but I do not know for sure whether that is the case.

Any thoughts on any of these issues is welcome!

Cheers,

David

[T-Square]

I am adding an addendum.

I have, with help from others in the Forums, discovered that some calculations--such as the Get(PageNumber) function--are evaluated from the perspective of the data, and not from the perspective of the interface. For example, if you create a calculation in your interface file that uses the Get(PageNumber) function, and put this in a report in your reports file, the function will not return valid information when you preview the report.

I'm not certain whether there is a clear delineation of which functions behave this way and what effects this might have in the separation model, but it does make the prospect much more questionable. If you are splitting you interface files up for any reason (as I have), it raises the prospect that you'll have a calcs table in each interface file, and you'll have to determine which calcs need to go into which file.

Additionally, it is likely that any generalized calculations table would have to be attached at every point in the relationships graph where a calculation context is needed. This would create a very messy relationships graph. While this is not necessarily a major problem, it is something that would have to be addressed in implementation.

David

[Razumovsky]

Hi David,

I'm not certain whether there is a clear delineation of which functions behave this way and what effects this might have in the separation model, but it does make the prospect much more questionable.

I think a lightbulb just went on for me. This should be treated as a hyptothesis, and I hope some of the heavys around here can confirm it, but I would like to posit a simple rule for which calcs need to be considered in the interface file for the SM:

all calculations that evaluate user interaction must be considered by context or how the records of the TO they exist on are being viewed.

This would include Get(PageNumber) and all of its Get(ilk) essentially by definition, as Get is reaching out of the calc to capture information specific to the nature of which a specific user is interacting with the files.

Have you discovered any non-Get functions that are problematic?

I am also very curious for an update on what steps you have taken and performance results.