Why only "pure data" in Data file?

[TheLagosChap]

Hi,

I've been reading a lot recently about the separation model as I would like to develop a Filemaker application that needs to run on a (slow) WAN.

I have found one "purist" approach that aims at avoiding anything else than just data in the data file, avoiding anything like calculations, summary fields etc

This requires what I see as significant cost (work) in the User Interface file in order to reproduce the same functionality (additional local tables, fields, relationships, even mirror tables...)

A very good example of this is shown in the videos from filemakermagazine (for example "The Separation Model - Breaking up your data and interface" but there's more recent ones as well).

What I have not been able to find anywhere yet is the actual reason WHY I should not put calculations, summary fields etc in the data file...

Thanks,

Serge.

[beverly]

Because these must go across the WAN?! Not that calcs should be removed totally, but how much can you do with scripted set field? or auto-enter calculations/lookups? The idea is that the data is just data. Because we don't have SQL calls that would be able to calculate and return the results, we use calculation fields. These have an overhead that can be optimized by not using them! I have clients that are using wireless remotely to connect to server. I have very few calculations. Yes, it's more work in the interface file (which is on each person's system, not on the server). But the speed is phenominal. Also removing all those interface (graphical) elements from the server helps with the separation where the WAN is slower. This method is somewhat like the browser method where a bunch of the work is done client side instead of server side. Same difference!

[David Jondreau]

There are two major reasons I hear in favor of data separation, speed and ease of update. I don't see why separating calcs from the data file would help with either of those.

I'd be surprised if calcs (stored or unstored) or summaries were any faster in an interface file rather than in the data file. The record data still has to travel over the network.

I think the "purist" approach is just an ideological stance, without a real justification.

[beverly]

David, use scripts to SET fields rather than calculate. It depends on what you need to do, but you can trim a lot of calcs out that way.

Beverly

[rivet]

Serge, over the last several projects I have embraced the data separation model (DSM) with no calcs (other then interface feedback, such as; record count, users online count) in my data table. I have chosen this option for a couple of reasons.

Firstly: since I have also been working with MySql of the past few years, that is how it is done.

Secondly: Client interest: Clients grow and so do their needs. I have had a few project where we migrate the data to MySql but keep the Filemaker interface ( filemaker > ODBC > mySql ) With the original project setup as a DSM and no calcs, it made the migration a very smooth process, Which kept costs down for the client, kept me as their developer, and the users in their friendly FMP environment. Not to mention, it opened the door for the client to access data via standard PHP etc.

As Beverly said "use scripts to SET the fields rather then calculate", your list/table views will love it.

And as always, once you invest in the mind shift, you will have a new set of reusable scripts and techniques for the next project.

[beverly]

think "how is it done in SQL" :)

[Bryan VonDeylen]

David, use scripts to SET fields rather than calculate. It depends on what you need to do, but you can trim a lot of calcs out that way.

Beverly

So if I wanted to eliminate Calculation fields. How would I eliminate a Calc field that combines First Name with Last Name in a list view?

Do I create a Text field [Full Name] and use a Replace Field Contents and do the calculation there?

[rivet]

Just to clarify, you want to eliminate field types that are calculations, but having a text field with Auto-Enter / Calculated Value is fine and really handy.

So for your text field [full name], I would have an auto-enter, calculated value of: first & ", " & last .

Any calculation that can not be handle with this method, should have the field set with a script.