Speed Concerns - Will Separation Help???

[RWX]

For the past year, I've been developing a rather complex system for my employer. They didn't have a very good idea of what they wanted, so development has been a bit trial and error (typical small business issues).

I now find myself with a rather complicated system (nearly 50 tables...yikes, I know!) that's a bit sluggish. It's not unbearable, but it could definitely be better. It's being served from a PowerMac G5 Dual 1.8 with 1+ GB of RAM. We don't have a lot of simultaneous users - maybe 10 on a heavy day.

I'm considering separating the system and was hoping to get some feedback re: speed. Once separated, can each user have a copy of the GUI file on his/her computer and access the data from the server? I assume so. I can't help but imagine that a separated file would perform better, especially one that is VERY GUI intensive and heavily scripted (like mine). Essentially they wanted me to create a database that looks and feels like an OS X application, so there are tons of layouts, loads of buttons, toolbars, etc.

Another issue is the long-term goal of integrating our three offices' systems into a single system. Right now each office maintains its own server as client info, etc. rarely crosses over. However lately that has been changing, so my boss would like to see all three servers merged. Again, it seems like separating the data, putting the data file on a server, and each user having a copy of the GUI on his/her machine makes the most sense.

I'm not sure how the shared server will work. Users might share one data file or we might need to sync data. It's not an immediate concern, but something we're definitely keeping in mind.

Anyway...I could ramble on forever about this. But...what do you think? Will separation help? Is separating a file this complex going to be a nightmare now? Any tips?

Thanks!

-Rob

[Søren Dyhr]

Once separated, can each user have a copy of the GUI file on his/her computer and access the data from the server? I assume so. I can't help but imagine that a separated file would perform better, especially one that is VERY GUI intensive and heavily scripted (like mine). Essentially they wanted me to create a database that looks and feels like an OS X application, so there are tons of layouts, loads of buttons, toolbars, etc.

The scenario is doable, but I wouldn't say 10 users isn't particuar burdening on the server as such, something else must be amiss. Extensive scripting points in direction of a less than convenient relations structure and a considerable amount of unstored calc's and summaries, and slow rendering of graphics point in direction of pasted images made in another tool such as Photoshop.

It's so that graduation made with native tools such as lines, circle and boxes renders much faster than pasted pixel-images, because the info transfered from server is draw a line from a to b of a certain thickness ...by and large would your idea only solve the graphics - but my hunch tells me that wrong datastructure is likely to be the problem here, they creap on you like a cheap coat, when developing ad hoc as I understand you have done it.

Where the aim of TSM is to keep downtime as low as posible, taking it for granted that the datastructure behind is as fully nomalized as posible anyway.

There are issues where the normalization tempts to make you think of a selfjoin, but the vast number of records involved makes it a silly idea ...so you dupe the found set to another table set to watch out for conflicting issues the selfjoin were ment for for that smaller scope ...and when the investigation has taken place deletes the cloned set. Eventhoug it's denormalization plain and simple as that!!!

I'm not sure how the shared server will work. Users might share one data file or we might need to sync data. It's not an immediate concern, but something we're definitely keeping in mind

Does this mean you're pear2pear'ing?? ...everything beyond 5 users requires a server!!

--sd

[goanna300]

I agree! I have been asking this question for ages. The separation of data from "presentation" is often considered to be the trademark of the high-end DMS's from the desktop-based systems. Presentation is separated for precisely the issues you mention; less data down the wire.

Does anybody actually have any experience with a Filemaker Separation Model in a Server environment? Or is the separation model still something for us geeks?

I certainly don't see Filemaker endorsing it anywhere.

Rob Said:

I'm considering separating the system and was hoping to get some feedback re: speed. Once separated, can each user have a copy of the GUI file on his/her computer and access the data from the server?

.....separating the data, putting the data file on a server, and each user having a copy of the GUI on his/her machine makes the most sense.

-Rob

[Søren Dyhr]

Does anybody actually have any experience with a Filemaker Separation Model in a Server environment?

If you take a look at this .pdf - does it give us a description of the troubles one of the pioneers in TSM'ing faced when migrating to 7.0:

http://www.newmillennium.com/clientuploads/pdfs/migration_case_studies.pdf

What I took not of was this in particuar:

One of the biggest technical hurdles that ECXS faced with FileMaker Pro 7 was record locking, both intentional and unintentional. "We had combinations, for example, when we set a field in a related record, we had to add an Exit Record script step." Instead of having to go through every script, New Millennium showed Honing how to use MetadataMagic to get an inventory of all his scripts, which allowed him to identify those that had similar steps or actions and update them much more efficiently.

It was this instruction that he found most beneficial. New Millennium gave him not just a tool but a methodology for working, and pointed him towards issues that he was previously unaware of. They helped him put together a list of priorities.