Relationships and the Separation Model

[DanBrill]

Hi,

When FM7 came out, I decided to be a good boy this time and read the manuals. They are advocating the Separation Model (SM) wherein the solution is split into three files: one for layouts and scripts, one for calculations, and one for the data. This is great (in theory) as it will make repurposing the solution or updating the solution for off-site users very easy.

In the attached file I've simulated this in one file by making a data table (People), a calculation table (Calculations), and a layout table (Calendar). Each record in the data table has a related record in the calculation table where the calcs take place.

In the calendar table the user enters a date in gCurrentViewingDate. CurrentMonth is the MonthName of gCurrentViewingDate. A portal should show all of the people who have a birthday in the same month as gCurrentViewingDate.

BirthMonth is the MonthName of the person's date of birth (DOB). If BirthMonth is calculated within the People data table, the relationship between the the calendar table and the data table works fine. But the point of the SM is to keep the calcs out of the data tables. If BirthMonth is calculated in the calculation table, the relationship fails since BirthMonth must be unstored since it is calculated based on the relationship to the data table. Of course, this is the entire underlying theory of the SM: all of the calcs will always be based on related data.

So am I missing something obvious, or is this a fatal flaw in the separation model? Can a field in the calculation table never be used as the right hand side of a relationship?

Thanks for your insights,

Dan

BirthdayTest.zip

[Kurt Knippel]

The seperation model does not required that calcs be stored seperately from data. In fact calcs are an integral part of the data model.

[DanBrill]

No, it require it, and doesn't make your solution fall apart to have a calc in the data table. But doesn't it violate the basic logic of keeping them seperate? The basic idea is that the data table has the raw data, and that everything that can be calculated from that data would be kept in a seperate table. To be forced to put calcs in the data table muddles the purity of the SM, and means that at times I'll need to add calculations to the data table in order to add new features, even if the raw data is already there. And this means going back to the bad old days of cumbersome import scripts to move data from the old data tables to the new ones.

Dan

[Fenton]

> Can a field in the calculation table never be used as the right hand side of a relationship?

Not if it's Unstored. I guess the normal rules apply. I've done very little as yet with the separation thing. I find that piping data through even several relationships is very useful; but only if the path is logical (and the relationships valid of course).

I this case I can see how you could go through the data file, in order to access the calculations. That is perhaps the intent.

If, on the other hand, you want to use something that requires calculation in the data file as a filter, i.e., as a target for a relationship, I can't see any easy way that you can avoid it (read on).

I did come up with an idea, to create the filter in the Calendar file. It would be a Custom function that produced a series of ranges of dates, for the current month, in a series of years, starting with say 1900; a muli-line unstored calculation field. You could use that to target the DOB directly. That would work, with no calculation needed in the data file. But yikes.

BirthdayTest.fp7.zip

[DanBrill]

Hmmm. Well, the 'Calculations via People' portal works, but it relies on the BirthMonth calc residing in the data file, which is what I'm trying to avoid. As for the custom function, I haven't played with those yet, but I get your drift. Yikes indeed! This isn't to say that it can't be done, or even that it isn't worth doing. It will be tedious, however.

Thanks

[Fenton]

I suppose one could think of the BirthMonth as a form of data, coming from the DOB. It could even be an auto-enter by calculation. What would that be?, a data field?, a calculation? It's some of each.

I think a more useful concept of a "data" field is a field that will never need to change because of business rules or changes in the interface. That is what you're trying to avoid. BirthMonth certainly meets that criteria.

I also think that the Separation method will never be perfect. I find that I occassionally need to add a data field when improving a solution, because the client becomes aware of something they neglected to tell me about. Which means importing all the old data into the new file. But it's also true that most tweaks are to other things.

[DanBrill]

Good points. Even if the client doesn't neglect to tell you anything (rare!) reality changes and new stuff needs to get added. So we'll probably never be totally free of having to re-import.

Having said that, I took your challenge of the custom function idea. The 'yikes' factor was not bad at all. This was my first attempt at a Custom Function, and I've got to say that it is really cool. These will greatly improve lots of things.

I combined a 31-line Custom Function with a repeating field (200 repetitions - 1900 through 2099), to create a repeating calc field that can be used as the left hand side of a relationship. The right hand side is any date field in any related table. So now you can type in a date in the calendar and the portal will show any date in that month in any year between 1900 and 2099. (Adding more years would be pretty easy if you were doing something like historical research and needed a longer range of dates.)

Dates will probably be the some of the harder things to work with in creating relationships. So this technique goes a long way toward solving that.

Anyway, its attached for anyone who is interested.

Thanks for the idea,

Dan

BirthdayTest.zip

[MoonShadow]

Brilliant idea, Dan, to separate this (pun intended) into its own section.

You frequently inspire me and open my mind to possibilities with your 'questioning' posts. You reconsider everything afresh, instead of accepting others' conclusions. Nothing would ever be discovered if everyone assumed someone else had thought it through from all perspectives. We each possess a unique view which should be tapped.

Even I can come up with good ideas. I believe in the saying that, "Even a blind hog can find an acorn once in a while."

There is no such thing as a bad idea ... only wrong timing and times change so everything must be constantly reevaluated with new knowledge and new tools (as with FM7). And all problems are solvable; it's just a question of who will achieve it; because they insist on constant reevaluation. Thank you!