Advantages of multi file solution

[Genx]

...What are the advantages of splitting a database up into multiple files?....

[Zero Tolerence]

If you have a separate file for say, your GUI then if/when you make any changes to it, you only have to update it, and not the other files. In the other files, you might or might not have the same data that your user has, it stops them from having to export/import their data. Those are the biggest ones I've ran into.

Having a separate UI is a real life saver for me.

[Genx]

...now theres a thought

[BrentHedden]

Much like what Zero has mentioned - I have all my calcs, relationships, & scripts in one file. All the others are for holding data. The only reason I would have to update the "other" files is when I add a field in one of the tables.

[Calantha]

Hello,

I was just perusing the forum for nothing specific other than to learn, and I came across the "separation model". I kind of understand what this is, but if someone has some free time they don't know what to do with and would like to provide me with an idea of what it is exactly.

You say keep your UI in another file and the data in another. So the user uses the GUI file which places the data into the data file? And the data is shown through portals?

I'm quite interested.

Thanks.

[Kent Searight]

1.) Create a new FM File called interface. Don't add any fields and DELETE the table that's automatically created. You don't need it!

2.) Create a new FM File called data. Create a table or two in that file.

3.) Go back to your Interface file and open the Define Database dialog and go to the Relationships graph. Click on the Add Table button in the lower left and a dialog appears. Scroll down to Add File Reference and select it. In the dialog box that opens, locate your Data file and add a table from it. Repeat as often as necessary to bring in new table occurrences and set up your desired relationships.

4.) Now create a layout in your Interface file and base it on whatever table you want. Add fields from that table directly to the layout. No portals needed for this (although portals CAN be added for more functionality)

That's basically it! Now you have a UI that's separate from data. Put all your scripts in the UI file.

Note: You may have to create relationships in your data file as well to make some lookups and calculations function.

Play around with this and I think you'll realize the workings and the possibilities.

Try this and it should make perfect sense. Good luck!

[Joe King]

I aggree with most everything written in this thread. The 'push' to combine all you tables in one file is not the most sound approach for larger solutions.

One point which no one has mentioned yet is that with the separation model it is possible to build a killer 'interface engine' which manages your layout, your navigation, your back buttons, your print engine, and a bunch of other 'add-on' type features. I start almost every FMP7/8 solution with such a file and I don't recreate this 'foundation' work which is typically very time consuming; therefore my time is spent on the 'real' business rules of the database and not housekeeping.

Most of my solutions are now four file solutions:

Interface Support

Interface

Data

Lookup Tables

Hope this helps....

Joe

[Kent Searight]

Joe King,

Would you elaborate on your 4 file solution? What is Interface Support and why don't you put your Lookup Tables with Data? In other words, what are you looking up that isn't part of your data, anyway? Also, could you elaborate on

killer 'interface engine' which manages your layout, your navigation, your back buttons, your print engine, and a bunch of other 'add-on' type features

?

[goanna300]

I totally agree with Kent, whose ontribution on separation is the simplest I've yet seen- and long-awaited.

Like Kent, I'd really like elaboration on all counts:

1) Why one-file solutions are no good for larger databases. (I assume you mean one *data* file *plus* one GUI;

2) The 4-file solution explanantion. (see Kent's post)

Steve

[FMDuck]

Personally (now nobody stone me) I don't feel the seperation model is useful for FM solutions in many (I didn't say most) situations.

First, I personally have never had a solution that requires changes to the ui without often requiring changes to fields. Validation, population or just plain ol' adding a field.

Second, FM lends itself to development of diverse solutions. When you do something that stretches FAR beyond the usual, the relationships get unique and to me it doesn't seem worth the time.

Third, although rare, there are solutions that are higly dependent on many complex relationships and with the addition of the Evaluate function, there are cases when the string to be evaluated needs to be local simply for the clearity. (No, you can't do a 'little' test of this - you will know big and complex when that wall hits you in the face.)

Fourth, (going back to the first one) If you have a solution that 'usually' only requires the ui file to be updates, you still need a process for updating the entire solution. You or your customer may be stuck with having to decide or remember which process to use and when.

All this being said though, I have to say I haven't seen anyones seperation model (I look forward to seeing what Joe has done) and think that it is likely practical in MOST cases but like anything else, needs to be considered before implementing.

[T-Square]

Jeff--

My experience is pretty much opposite to yours. I have made extensive use of the Separation model to enable me to push out UI enhancements to my clients quickly and easily (I've reported on this in other threads). The update process with the SM is simple: I email my client a replacement UI file (which is possible because the UI file is a manageable size), and they plunk it down on top of the old one. Update done, client happy. There's no special commands needed, and even the most basic user can manage this.

As I've noted elsewhere, in prior versions, I had to work with each client individually, have them send me a CD of their data (due to its size), munge the data, and ship it back to them--all with associated downtime.

Because of the SM, I have become incredibly aware of when and whether I need to modify the data structure, and I will do so only under duress. One huge area that I am examining is whether I can move calculations out of the data file altogether, although as you suggest, this appears to be quite complex to achieve. The calcs are the area I find most likely to want to change.

I'll note that my UI file includes a number of its own tables--tables that are used by the application, as opposed to tables that are used by the client. For example, I put my Help table in the UI. I also have a Globals table for all my global fields, and a Config table for things like version number and date and trial version status. Client-related settings (such as default view) are stored in the data file.

I'll also note that because I migrated my solution from an earlier version of FM, my data file contains a slew of relationships that I will gladly remove when I get around to figuring which ones are actually needed in the backend for data management, and which are not.

Cheers,

David

[SurferNate]

Interesting qualification. What I notice is that you work hard to avoid messing with the data structure. I hope that someday I will be wizard enough to get my data structure complete and perfect the first time around. Or to remember every possible field and data relationship that might be desired in the future.

Mind you that I'm not arguing. I can see quite a number of benefits. I'm just pondering publicly.

Is it practical to have both a bound interface and a SM interface? That would be a good stepping stone for me. I have not even explored that yet.

[Genx]

... i suppose being able to update the UI would be an advantage but it seems a bit burdonsome to do this in filemaker... besides when would you just update a GUI, i mean im sure that would be much easier to get right the first time than the complete table structure and all fields?

... you could always perfect an update script that exports all the data out of the old file and into the new one which you could send your client instead of just the UI.

Anyway after a lot of experimentation i figure theres no real point in seperating the files when you dont have to... if you want to do that go use access or vb and sql, filemaker seems to have been designed to be all in one... some interesting replies though, thanks lots.

[Zero Tolerence]

Heres what I use it for.

I run FM7SA, all the data is stored on the Server. While having a pretty UI on the server would be great, having all those graphics in a file on your server can be an unneeded burden on the server itself. Each graphic has to be "re-written" each time a layout is loaded, and that can stress out a server quickly if your close to the limit of 250 users.

So, I have a separate UI file that I keep localy on the machines that connect to the server. We use pre-force and Apple remote desktop to update the UI when needed.

Now I realize this is not what most people use the SM for, but it works great for me in this situation.

[T-Square]

alfgenx--

with regard to the import/export scripting--been there, done that--and hated every minute of it. It is difficult in FM to figure out which files are being targetted for import/export in a script, and it is my bad luck always to somehow find the oldest copy of a datafile to migrate...

As for Access or SQL Server: well, that's just fine, unless you have clients using Macs. Nor am I industrial enough to want to roll my own package using C++ and MySQL, which would have to be compiled for different OS's, etc........

[Genx]

Guys, thats all great, but i still refuse to concede to the fact that you would ever update a GUI without adding any fields... i mean theres no real point is there?... anyway, on to the seperation of the GUI from the datatables for the purpose of hosting... doesnt the end user have to deal with the size of the images in download over the network? i mean how does the fact that youve got all your images in one file with tables referenced improve efficiency when the user is only really limited at the speed they can download the images?... Someone please set me straight on the whole issue...

Cheers, Genx

[T-Square]

Zero's referring to the images on the layouts, which *won't* be downloaded if the UI is on the client.

Here's an example of UI changes without data changes: I'm working right now on adding credit card payment features in my app, using Waves in Motion's plug-in. The plug-in has all the fields it needs, and I already have a Payments data table with fields for storing payment number, date, etc. But for that to work, I need to create scripts and layouts that gather the appropriate data and pipe it accordingly. Then, if I want to create a monthly auto-billing feature, I have to script that as well.

None of that affects the backend data structure.

David

[Genx]

... lol i knew i was missing something, never though of keeping the UI on the client : ... yeah fair enough though i still think that a)... you shouldnt have so many graphics in a UI that it would take so long to download them over a 10-100Mb/s bandwidth range... and : that changing the backend structure would be unecessarily burdensome... anyway, cheers, i can actually see some benefits of it now, sorry bout being a pain

Genx

[Goopie]

I come from an Access background and i can think of numerous advantages of splitting a database. Just a few:

1 Why always back up a constant such as the GUI. Why not just back up the data file.

2 By splitting the database you can have different front ends address the same data. One front end is (eg) for data entry and the other for analysis; thus obviating the need for security privileges within the database.

3 Changing the interface for a client without having to import the data.

Perhaps it just comes down to what youre used to?

Now if only i can get my portal to act as a subform a la Access I would be very happy lol.

[Genx]

im just changing my entire point of view... 2 way db splitting has become my salvation... i can now actually find things that i need to in my front end relationships without having unecessary lookup tables clotting up my view... and working with two files also stops me from having to have unecessary layouts which just have all the fields in a table for the purpose of import export on any particular layout cluttering my front end... overall ive found that a 2 way split will make for a much cleaner and also efficient solution

genx

[hennaquick]

At the 11th hour of preparing my database for roll out, I remembered this separation technique from class. I am developing an application that will run from a remote server but will be storing the scripts and such on the local server. How exactly are the tables, layouts, scripts and such divided between files ?

[Ender]

You can divide interface and data files up however you wish. But it's not clear what you plan on putting where, with a 'remote server' and 'local server'. If you have a local server, why not put everything there? Is this to host to multiple remote locations or something?

[Genx]

Just for the sake of it. A poll :

[Genx]

I want more poll vote thingies :(

[Inky Phil]

Pole vault thingies ?

[Genx]

Thats it : :

[greg@work]

having only just got my FM8.5Adv and being a previous Fm5.5Dev user I can say that seperating the data and GUI would have saved me countless hours. Needless to say I am now embarking on a redevelopment of a few of my solutions to the seperation model - this is really cool :)

[Genx]

I'm just curious about the 3 users that split their solution in some other way?

[harvest]

Maybe it's these guys that have a third layer in between for business-logic.

I've established a separate file for printing because I can distribute new GUI files to different customers without having to change reports which are customized for CI...

Holger

[Genx]

Hi harvest,

I sort of get it, but could you explain a bit further?

Cheers,

Genx

[harvest]

Hi Genx,

I can't explain in depth, what people do with a third layer in between GUI and data but I think, the goal is to get a totally flatened data-file without any calculations, relations... All these calculations are done in their so called Business-Layer which doubles or mirrors the table structure of the data-file.

My goal with data and GUI separation was to get around these ugly updating-processes, we all know from FM < 7. When I did my first application in FM7 and thought about selling it a second time to a different customer I had to acknoledge that all layouts for printing in the GUI-files were based on the CI of the first customer. Thus I thought about a solution.

First idea was to generate an account for layout-management in the GUI-file and teach people how to customize their reports. The second thought was about having a separate print-file. Datahandling between GUI and print-file isn't easy because GTRR can't be used, one has to transfer the selection of data that is to be printed e.g. via scriptparameter in a multiline-key. But it can be done and now I can give different customers a new GUI-files and there is no need to recreate reports.

Have a nice Weekend

Holger

[Genx]

Interesting, i have the same issues, but mine reside more in reports that can be replicated in HTML -- i.e. brochures etc. etc. i just use xml style sheets to manipulate the data -- avoiding the need for the third "print" file that you use but still having some files custom to each client i suppose. Still not sure about the business-logic? Might look it up though.

Cheers,

~Genx

[T-Square]

I'm one of those Other People, and I checked Other because I (like Harvest) have a separate Reports file.

David

[Genx]

Okay, well that sheds some light on a few things, and gives me a couple of new ideas .

Cheers guys.

[Brudderman]

I checked Other because I (like Harvest) have a separate Reports file.

I'd be interested to know how the report file is structured. What is in there other than layouts? And do you pass data like Harvest with a multi-line script parameter.

Sorry for the dumb questions, but I'm having trouble visualizing how this works. A simple demo would sure be nice; maybe someone has one. :qwery:

Thanks!

James