Why no calculations in Data File?

May 8, 200718 yr

I am converting an old dB to the separation model, but I don't get why I wouldn't just keep the calculation fields in the data file.

For example, I am running a medical office which which requires authorization from insurance companies every 3 months for a procedure we repeat weekly on a single patient. So, I have the Auth_StartDate (Date field) and an Auth_EndDate (Calculation field) which is automatically calculated and populated as the calculation [Auth_StartDate + 90]. I then have another field, Renew_AuthDate (Calculation field) calculated as [Auth_EndDate-14] so my staff are prompted to renew the authorization from the insurance company 2 weeks prior to expiration of the current authorization.

Why would I want to separate this calculation data? Then, the fields Auth_EndDate and Renew_AuthDate would be in the second Calculation file but they still contain data. So, this second file would actually be a calculation and data file, correct? That ultimately means I have one data file, one calculation/data file, and one interface file. Am I missing something obvious?

Any help would be appreciated. It is a simple question and you guys have been really helpful. I have read a lot of the posts in this section on SM all the way back to the beginning- great resource.

(I plan to upgrade to FM8.5 during this rewrite).

May 8, 200718 yr

There is no requirement of The Separation Model, as described by Colleen Hammersley and Wendy King, that says you shouldn't place calculations in the data tables. I'm not entirely certain myself where this belief arose but my suspicion is with TSM detractors who didn't bother to understand exactly what it was to which they were opposed.

Colleen and Wendy advocate separating the data tables from the UI logic where practical. If a calculation is simply derived data then it belongs in the data tables. If it represents presentation logic then it should be placed in the presentation file where practical. The separation model therefore isn't a set of rules to be followed but a development style or methodology to be employed.