Can anyone give a critique about the speed and behavior of a solution
where the data is separated versus one that is not? I've heard some
pros, but not much cons.

My database is served by Filemaker Pro 7 Advanced using xserve dual G5.

Thanks for your comments.

In article <2005092114124516807%sertian@gmailcom>, sertian (AT) gmail (DOT) com
says...
There aren't really any outright cons.

It doesn't always live up to the hype of being able to just swap the ui
file to deploy upgrades.

Its a bit more work to build.

Managing security become harder, and dilutes the code/data separation.

It can also lead to bad programming if you start valuing "not
importing" above "good coding". Its often possible to implement
something within the 'screens' file that really belongs in the data
file... e.g. instead of setting the security options for the field where
it belongs in the data file you could just write a bunch of scripts in
the screens file instead to try and enforce the policy.

Really, there's no real reason not to go with data-separation unless
your banging up against the open file limit or something. It helps
modularize development, a good thing. And it isn't usually -that- much
extra work.

For the average in-house developer I'd advocate data separation as a
system maintenance and modularisation technique, not as something that's
going to eliminate imports.

For the shrinkwrap developers, sure, delivering minor bug fixes to many
customers can be greatly eased by data separation, but for custom
solutions where there is only one server, its often still easier to just
tweak the live system, even if its been 'data separated'.