Has anyone done benchmarking to see what benefit there is when building a stand-alone app to using tables local to the file vs. external when the external tables are part of a much larger system?
I've got a "mothership" file with ~150 tables and have been asked to build a standalone app based on maybe 5 of those tables for people in the field who would be connecting on iPads over cell via FM Go or WebDirect. If I make the 5 tables local to the app, I'll have to manage syncing data between the app and the mothership, but the app will be super lean and as performant as I can get it. If I use external tables from the mothership, I won't have to worry about syncing but I'm concerned the weight of the mothership in the background might negatively impact performance to the point where the app is painful to use.
Mike, we don’t like the way external files behave in FM Go and would prefer to keep the app independent of the main system’s files, only exchanging data on demand.
Having been at John Renfrew’s session at the recent EngageU in Malmö, we’re seriously investigating using OData as the communication between the app and the ‘mothership’ data.
Are you collecting data, distributing data, or a mixture?
I've just seen that @AndyHibbs has suggested oData. Either oData or the Data API are both going to allow you to control transfer of data between the mothership and your remote clients. That is really most useful if you expect your mobile users to be out of network range. If you can expect them to have good network coverage then linking directly to the mothership is easy.
As for performance, the smaller the better. FMGo seems to be really good at managing it's data requirements. It doesn't download every record in every table. It gets what it needs. It's best when you design for Go.
You can experiment easily. For instance, start by creating a new file on the server, and link the five tables as external data sources. Use a light layout theme, like Apex, then connect and see what your performance is like.
You probably want to think about using narrow tables. You get a performance boost by de-normalising your data, which will make your table wider. The extra data load is offset because you have less relationships and less table occurrences.
I did side-by-side tests of light-weight files, one with local tables and the other with externally linked ones. The first time each was opened on an iPad over a cell connection, the linked file took almost twice as long to open (~14 sec vs ~8 sec). Subsequent openings, after stuff was cached, the linked file took ~1.5 times as long to open (~4-6 sec vs 7-10 sec). However, (A) this represented a difference of just a few seconds, and (B) the loaded layout included a pop-up menu whose value list referenced a table with ~5 years of data. Once I added a filter limiting the data to ~50 days-worth, the file opened a lot faster.
Bottom line is that, even though keeping the tables local so there's no need to reference the mothership kept things snappier, we're going to build out using linked tables, leaving ourselves the option to switch over later if performance becomes unacceptable. The speed difference was small enough that it wasn't worth going the local tables route and having to build a data-synchronization mechanism. That said, @AndyHibbs , can you say more about what you don't like about "the way external files behave in FM Go?" I didn't see anything particularly painful about that in my testing.