separating files and development

[Rich K.]

Hi --

Is it wise to leave your data in its own file and use another file for the GUI? Is it wise to do this right from the get-go. Is there any advice about this? Is this called separation model? Does splitting out your data down the road cause some inherent problems.

This seems to be a little of a pain when developing.

Also it seems there are certain things you can no longer do ... for example ... I have a field that uses a Lookup List which wants to go against a TO ... well my TO is specified in my other file; ?inaccessible? to this file.

Regards,

Rich

[David Jondreau]

Like any other design choice, whether to use the separation model or not depends on what goals you're trying to accomplish with your database.

Personally, I've never found the need and think it's a false dichotomy when it comes to Filemaker. But others love it. What do you hope to achieve by separating the data from the interface?

You can easily add TOs of tables from another file. You just need to add that file as a data source first.

[JesseSFR]

No matter what route you choose, it would be smart to make it up front because after you have gone one way or the other it is very hard to switch.

For instance say you choose not to use the separation model and eventually change your mind. You would be forced to go through a pretty hairy process to go ahead and separate the data from the ui.

I personally love the separation model and would definitely suggest it for a couple of reasons.

1. It's nice to be able to work on just the ui file on a test server and then transfer it to the live system

2. The relationship graph in the data file tends to be much simpler then in the ui file so when you are changing schema it's not as convoluted to trace your path

No matter what choice you make it's hard to argue against the decision with anything but personal opinion.