3 part separation model Possible?

[Heathbo]

I was looking for something where the Data File holds just the data. The GUI File holds the relationships and calculations. That way if I have to make updates, the end user doesn't have to reimport their records.

For example:

File(A) is the GUI File = The GUI

File( is the Personal Records = All DVDs you own.

File© is the Data Files = File where all possible DVDs are stored.

Basically, you browse the Data Files and Personal Records through the GUI file. You add records from the Data Files (through ID# ?) to your Personal Records.

I want the Data Files and Personal Records to be nothing but data. All the calculations and relationships in the GUI file so I can make updates without worrying about messing up the user data.

[HarryGlos]

Hi Heathbo, Hey is that a heathBar with a lisp? :

Yes, you can have files A, B and C. You can even be a real wild and crazy guy and have files 1, 2 and 3. Just so you understand when you do it that you’re jumping through hoops for no plausible reason. You said

I want the Data Files and Personal Records to be nothing but data. All the calculations and relationships in the GUI file so I can make updates without worrying about messing up the user data.

This is the intent of the separation model. An interface and a data file. You make an update, you replace the old interface file with the new one and that’s it. I’ve built systems with more than one data file, but you need to be talking a huge amount of data to necessitate that. And this stuff you here about every once in a while to have a separate Interface, Calculation and data file, although nice for conversation at an office party, it adds complexity to a system that there is just no justification for. Nadda, zero, sip, oops I wanted to say Zip, I must have been thinking of Mr. Vodka...

Hope this answers your question… I’m sure you’ll see some other FileMaker-In's weigh in on this and dispute everything I just said and that is perfectly fine, just so you understand when the dust settles ol Harry is right… :

Harry

Edited July 27, 2007 by Guest

[Heathbo]

OK, say there is only a GUI file and a Data file. All of the calculations are done in the data file, right? If thats so, how do you then make changes and fixes to the calculations without requiring the end user to reimport all their data? I can see this being a major problem if the end user has a ton of data.

[Vaughan]

Yes, the "advantage" of the separation model only applies to interface file updates. Once a field changes, it's back to SOP. And it's the same amount of "problem" whether there is one record or a million.

On the whole, importing user data between updates wouldn't be as much a problem if developers put as much effort into *making* it easy (by scripting and forward planning etc) as they do other features. But that requires developers realising the problem's importance to a commercial-quality solution.

[HarryGlos]

Hi Heathbo,

Vaughan is “Right Again” as usual and his statement that follows is well worth seeing again.

Vaughan Said: [color:blue]On the whole, importing user data between updates wouldn't be as much a problem if developers put as much effort into *making* it easy (by scripting and forward planning etc) as they do other features.

Look if you’re messing around at home with something keeping your stamp collection, maybe you need not worry about this kind of thing or even SM for that matter. But if you’re building something more substantial, maybe something you’ll be networking. Not to build in script routines for data import/export and at least rudimentary data management is just well, suicide. Now anyone sitting there reading this thinking, “What’s the big deal, I don’t even set backup routines much less back up my stuff"! You're right-A-Rooney, No reason to sweat the import-export routines... :

Harry

Edited August 4, 2007 by Guest

[Cortical]

one small addition: one situation where I find it convenient to have a second 'data' file is a Help file. This is one component that invariably continues to develop some time after the GUI itself is settled and stable. New users come along, (secretaries in particular) and reflections change with time...

This data could be built in the GUI, not usually big, but other considerations may come into play.

[HarryGlos]

Cortical Said: one situation where I find it convenient to have a second 'data' file is a Help file.

Hmmmmmm. Well, I mean I guess you could, but you're using 8 Advanced and I'm not sure why you would want to? Even with a large solution I'm not exactly sure why you'd want a Help file unto itself. Not with all of the built in helps right within the shell...

Maybe you could explain a little more of your thinking.

Live Long & Prosper,

Harry

[Cortical]

Contextual Help. I add this to a number of solutions, sometimes one help button per layout explaining what the layout functions are , and how to use them, sometimes a half dozen or so per layout, one per 'panel' explaining the associated functions, or input limitations...

A simple script parameter hard coding the help record ID on the button(s), allows go to related record raising a pop window.

I am currently implementing a video (screencast) variation on this as well.

This is not 'FileMaker' help, it is help data immediately relevant to the data input and interpretation...

[Heathbo]

What I'm working on is more substantial. I was using the DVD Video example as a way to explain what I'm looking for. I'm under a non-disclosure agreement. So the DVD Video description was a way around it.

Now, is there a way to perform all the calculations in the GUI table rather than in the Data Files table?

[Vaughan]

"Now, is there a way to perform all the calculations in the GUI table rather than in the Data Files table?"

No, because the GUI file doesn't have an data tables in it.

Other people have attempted a full separation model, with data, business logic and interface layers. The business logic layer can be done by creating a "shadow" table of data (one record in the BL table for every record in the data table) but this increases complexity quite a bit. Every add, update and delete operation has to work on two tables, not just one.

The returns begin to diminish pretty quickly.

[DataMate]

you can have as many data files and GUI files as you need, I have a client that has 3 data files as they are getting too slow to back up, and one with 7 data files and 38 interface files all tied together much like a big bowl of nicely laid out overdone spaghetti. One GUI with 1 or 2 data would be the best arrangement I think