Where do you put the calculations?

[douglasgifford]

If the purpose of separation is to keep the data in one place and the 'business' in another, where do you put the calculations? The usual FM model is in calculated fields, but that would (most simply) stick them right in the middle of the data tables, which runs against the model. Maintaining related tables in the business end just to hold calculations seems rather messy. Can user-defined functions deal with this, perhaps?

[Vaughan]

Welcome to Reality.

Proponents of the Separation Model build another table layer -- Business Logic -- into the system which contains all the calculations and summary fields. This level needs to have records that exactly mirrors the data model, which presents a challenge.

I'm currently working on a solution and implementing a separate interface file for it. For pragmatic reasons that's the depth to which I am prepared to meet the ideal of the model. My data file has some relationships and calculation fields in it.

I'm not prepared to throw the baby (FileMaker Pro's inherent simplicity and elegance) with the bath water (idealised data models).

[Anatoli]

I started with separation because of remote access over slow line from distant branch. The system is much more responsive after initial delay (open used files).

It can be called "Interface file"

[Rory Bowman]

I am playing with this question myself and realize that I can save a *lot* of work by putting all value lists, globaltemps, scripts, graphics/logos and development notes in a separate file. It's not total separation but it is a good start for me.

Since the two main projects I am working on are both in FileMaker 5 I don't have the extensive commenting functions I might want, so this last bit about development notes has been really handy. A quick question, though:

What do you call this "business logic" file or table? I have seen it called "Prefs" and "Temps" and even one where there were separate tables for value lists and scripts. Currently I am calling mine "Developer" but is there a convention for naming such a file? If you have a strong preference, why?

[Steven B]

Proponents of the Separation Model build another table layer -- Business Logic -- into the system which contains all the calculations and summary fields. This level needs to have records that exactly mirrors the data model, which presents a challenge.

Could you elaborate a little?

Do you mean to say that 'Business Logic' is a file which is a complete duplicate of the data tables file (with the data); which has calculation fields, summary fields, etc. added?

Thanks,

Steven

[RalphL]

Take a look a look at a Separtion Model for a Many to Many Relationship

http://www.fmforums.com/threads/showflat.php?Cat=0&Number=137763&page=1&fpart=3&vc=1

[dxoft]

Do you mean to say that 'Business Logic' is a file which is a complete duplicate of the data tables file (with the data); which has calculation fields, summary fields, etc. added?

You don't need to duplicate all the data, just your primary key.

Then using that key you can generate in the business logics file all the calc and summary fields you want. _Provided_ you take care of the refresh issues both in your business and Ui files.

You must keep the data and business files in sync, which is not all that hard to do, especially if you use a plug-in such as EventScript that relies on calculations to trigger scripts when modifying fields.

The refresh issues are problematic though. For instance, a calculation field, even unstored, must often be present on the layout you're looking at to refresh properly. Keeping such fields (business) and the data they reference (data) completely separated from the file where they appear (UI) can lead to severe design issues. For instance, in your UI file, on a layout referencing your data table, if you modify an entry, a calc field in the business file based on that entry will _not_ be updated automatically _unless_ that calc field is also present on the layout you're working on. Then and only then will the refresh occur automatically.

Given those facts, I believe it makes more sense to bypass the business logics file as discussed here for now and just go with two files, one for the UI (including globals, scripts, value lists etc.) and one for the "data", which still includes calculation fields based on those data.

The data file does not have to contain any custom functions, value lists, globals etc. And it can only offer a couple of scripts, used to manage the login, to back-up/restore data and to recover the file for instance. The rest should reside in the UI file.

A third "business" file could still be created to handle reports for instance. Using an export/import of the data on which to base the report, you can then generate in that third file all the calcs/summaries you need without having to maintain on a permanent basis an exact duplicate of your data records. Then you delete the imported data till the next set is exported/imported.

But that's as far as I would go into the separation model right now.

[Roy Osborn]

Building a mirror file so you can have seperation seems crazy to me. I do see a huge advantage of seperation, but if it requires such a massive amount of data duplication, then it's advantages are outweighed by disadvantages.

[RalphL]

I don't know what you mean by mirror file. The BR table is a one to one relationship to the data table. They both haave the same primary key, that is the only duplication. That is not a massive amount of data duplication.

[DLS]

One problem I see (someone enlighten me if I am wrong) with the BR file for calcs is that you cannot store/index any calcs at all because they all reference related fields. In large databases this can slow things down. Ever perfom a multiple ctiteria find on several unidexed fields? Even worse remotely. Not to mention the added complexity of the third file. At this point personnaly the disadvantages outweight any advantages. Much easier to use naming conventions to "separate" derived data fields in the Data tables.

I am putting all value lists in the Data file and then referencing them from the GUI file value lists. This way I can modify a GUI file and replace it and if my client has added values to lists they are still in the Data file. Afterall, value lists are data.

[pezagency]

You don't need to duplicate all the data, just your primary key.

Bingo My "business object" gets the primary key, my data table gets the foreign key. What is the best way to duplicate keys in FM7? Use the "allow creation of related records" in the preferences?

You must keep the data and business files in sync, which is not all that hard to do, especially if you use a plug-in such as EventScript that relies on calculations to trigger scripts when modifying fields.

I'm not sure this is true, but I haven't worked with FM7 long enough to find out. I would think that a relation will take care of this?

And, as far as I know, building a view table for the user interface wouldn't be out of the question. Any relational logic that's only needed for the UI shouldn't be included in the business logic layer. My thoughts on separation are simple enough: encapsulation.

The data file does not have to contain any custom functions, value lists, globals etc. And it can only offer a couple of scripts, used to manage the login, to back-up/restore data and to recover the file for instance. The rest should reside in the UI file.

I agree with this. However, I would include the scripts as a seperate file free from the data, for portability. Is that practical for FM7?

A third "business" file could still be created to handle reports for instance. Using an export/import of the data on which to base the report, you can then generate in that third file all the calcs/summaries you need without having to maintain on a permanent basis an exact duplicate of your data records. Then you delete the imported data till the next set is exported/imported.

Creating seperate report files seems like a smart idea.

I think people who are having trouble understanding modular systems should look at the innards of a PHP application. Reusable classes, reusable code.

[pezagency]

You don't need to duplicate all the data, just your primary key.

Bingo My "business object" gets the primary key, my data table gets the foreign key. What is the best way to duplicate keys in FM7? Use the "allow creation of related records" in the preferences?

You must keep the data and business files in sync, which is not all that hard to do, especially if you use a plug-in such as EventScript that relies on calculations to trigger scripts when modifying fields.

I'm not sure this is true, but I haven't worked with FM7 long enough to find out. I would think that a relation will take care of this?

And, as far as I know, building a view table for the user interface wouldn't be out of the question. Any relational logic that's only needed for the UI shouldn't be included in the business logic layer. My thoughts on separation are simple enough: encapsulation.

The data file does not have to contain any custom functions, value lists, globals etc. And it can only offer a couple of scripts, used to manage the login, to back-up/restore data and to recover the file for instance. The rest should reside in the UI file.

I agree with this. However, I would include the scripts as a seperate file free from the data, for portability. Is that practical for FM7?

A third "business" file could still be created to handle reports for instance. Using an export/import of the data on which to base the report, you can then generate in that third file all the calcs/summaries you need without having to maintain on a permanent basis an exact duplicate of your data records. Then you delete the imported data till the next set is exported/imported.

Creating seperate report files seems like a smart idea.

I think people who are having trouble understanding modular systems should look at the innards of a PHP application. Reusable classes, reusable code.

[pezagency]

You don't need to duplicate all the data, just your primary key.

Bingo My "business object" gets the primary key, my data table gets the foreign key. What is the best way to duplicate keys in FM7? Use the "allow creation of related records" in the preferences?

You must keep the data and business files in sync, which is not all that hard to do, especially if you use a plug-in such as EventScript that relies on calculations to trigger scripts when modifying fields.

I'm not sure this is true, but I haven't worked with FM7 long enough to find out. I would think that a relation will take care of this?

And, as far as I know, building a view table for the user interface wouldn't be out of the question. Any relational logic that's only needed for the UI shouldn't be included in the business logic layer. My thoughts on separation are simple enough: encapsulation.

The data file does not have to contain any custom functions, value lists, globals etc. And it can only offer a couple of scripts, used to manage the login, to back-up/restore data and to recover the file for instance. The rest should reside in the UI file.

I agree with this. However, I would include the scripts as a seperate file free from the data, for portability. Is that practical for FM7?

A third "business" file could still be created to handle reports for instance. Using an export/import of the data on which to base the report, you can then generate in that third file all the calcs/summaries you need without having to maintain on a permanent basis an exact duplicate of your data records. Then you delete the imported data till the next set is exported/imported.

Creating seperate report files seems like a smart idea.

I think people who are having trouble understanding modular systems should look at the innards of a PHP application. Reusable classes, reusable code.

[pezagency]

[color:"purple"]I am putting all value lists in the Data file and then referencing them from the GUI file value lists. This way I can modify a GUI file and replace it and if my client has added values to lists they are still in the Data file. Afterall, value lists are data.

With FM7 I am going to put all value lists in a seperate FM file. I can also create hash tables, etc.

This file goes into the business layer, as value lists are subjective. Unless the list is being used as a "simple table" (I don't know the correct term for that--one dimensional array?), I wouldn't include it with the data files.

For example, creating an address data table, I would include the states as values in the data table, but I would not include a value list of a categorization of those states.

[pezagency]

[color:"purple"]I am putting all value lists in the Data file and then referencing them from the GUI file value lists. This way I can modify a GUI file and replace it and if my client has added values to lists they are still in the Data file. Afterall, value lists are data.

With FM7 I am going to put all value lists in a seperate FM file. I can also create hash tables, etc.

This file goes into the business layer, as value lists are subjective. Unless the list is being used as a "simple table" (I don't know the correct term for that--one dimensional array?), I wouldn't include it with the data files.

For example, creating an address data table, I would include the states as values in the data table, but I would not include a value list of a categorization of those states.

[pezagency]

[color:"purple"]I am putting all value lists in the Data file and then referencing them from the GUI file value lists. This way I can modify a GUI file and replace it and if my client has added values to lists they are still in the Data file. Afterall, value lists are data.

With FM7 I am going to put all value lists in a seperate FM file. I can also create hash tables, etc.

This file goes into the business layer, as value lists are subjective. Unless the list is being used as a "simple table" (I don't know the correct term for that--one dimensional array?), I wouldn't include it with the data files.

For example, creating an address data table, I would include the states as values in the data table, but I would not include a value list of a categorization of those states.