Design Decisions - Single vs. Multi-File Solution?

[RWX]

Now that I've had a few days to explore 7 Developer, I'm starting to think about how to migrate my current project. The project was started in 6 and hasn't been deployed in any form yet. It's about 25% finished, at best. So, the way I see it, no time like the present to move to 7.

Now that FM files can contain multiple tables, what's the incentive to relate individual files vs. using a single file with multiple tables? I'd be very curious to hear anyone's thoughts on this as I'm essentially starting this project over...so I can take any approach I'd like.

Without going into too much detail, the project I'm working on is for a school. It handles student records, class enrollment, invoices, payments received, and some basic task management and scheduling for the sales force.

Thanks for your thoughts!

-Rob

Version: Developer v7

Platform: Mac OS X Panther

[Ocean West]

I think time wise it may be faster to redevelop using a single file approach but the real question is not singe file / mutli-file is more on the notion of separating your user interface from your data. OR modularizing your solution.

If your solution is all contained in a single file there is little extra you need to think of in regards to security it is all handled. If you use multi-file solution then I believe you need more planning will be involved in securing & managing your solution.

If you are developing for in-house and plan to be around for a while. There may be different reasons for the design approach if you were to develop a Shrink Wrapped product. Where you must manage upgrades & maintenance.

I would say that it is probably easier to develop singe file FIRST then if the design parameters become clearer that you should split up you solution it would be a matter of duplicating your file and pruning it down to the elements you need. Until the 3rd party tools come out and are put thru their paces for merging "separate" file solution.

[Vaughan]

For me, a single file with multiple tables has saved heaps of startup, shutdown and other navigation scripts (most of which were pretty hacky anyway). The single-file design also dramatically simplifies passwords and user accounts too, the management of which is pretty spiffy in FMP 7 but becomes almost trivially simple when one file holds a dozen tables.

The "separate interface" issue I have not yet explored: it sounds promising but it'll have to wait for another project -- or self-project more likely.

[Steven H. Blackwell]

I suspect that in a year we will see that most FMP7 deployments of any complexity will be using multi-file, multi-table design. But it's a bit early yet to say.

My view is that while single file, multi-table does make account management easier, that this should not be a governing factor. Multi-file account management is not difficult. You must however set it up correctly. Watch for the upcoming issue of FileMaker Pro Advisor magazine.

Steven

[Fenton]

This question of how many files and tables is really going to require some rethinking. So many options, I no longer know which is the right one anymore. In most cases, I think either way would be fine; but using at least some of the new ways would be better.

On situation which would clearly benefit from tables would be where you're jumping through hoops to do Finds in more than one file.

I think I will at first go for a "modular" approach, putting what are now files of one "group" together. So rather than having say 20 files, I would have 6-7 files, with about 3-4 tables in each (with a central "menu" file, as I have now). At first these would be combination files, with scripts and data.

Eventually I would move toward even more centralization, but with separation of the scripts and data. However, until you have them separated to the point where no real changes are made to the data files, you would still have to do the "update import" of the data file. Still, as you move in that direction, you would be no worse off than you are now, and eventually in a much better position.

I guess the final result of this logic would be one data file, and one interface file. But until we get some method to organize scripts I cannot imagine doing this with a large solution. And the relationships, table occurrences graph; perhaps when I get my 4' display (that would be cool, a huge graph with everything -)

Schools solutions, on the other hand, seem like one of the likeliest candidates for combining tables. From what I've seen (I haven't built a complete one myself, just parts) there are many files, in a fairly fixed inter-related hierarchy. You already know the structure. There doesn't seem to be all that much complicated business logic; it's mostly just data and relationships. The main functionality is Finds and reports, often across "files."

The only "module" that is kind of separate might be the task management and scheduling. All this is just my uninformed opinion. But I say go for it and see how it works.

[Steven H. Blackwell]

There will be more on this in a Migration Methodologies paper to eb relesed this week (hopefully). Keep watching the FMI se site:

http://www.filemaker.com/upgrade/techbriefs.html

Steven