Adding tables to legacy solution - separate files or single file?

[drookwood]

I am starting work on a major update to a system that I have inherited from previous developers. The current solution uses multiple separate files as it was originally developed in Filemaker 5 and 6. I need to add more tables to the solution - does it cause any issues if the new tables are all added within a single file and relationships set up with the existing files as required?

Eventually I anticipate using Filemaker 8 to get all the tables into a single file so this would be a step in that direction if it does not cause any problems to run a mixture of multiple tables in one file alongside the existing separate files.

[Ender]

Using a mixture of multiple files and multiple tables per file is no problem. If you have a large system (say over 30 tables,) then a multiple file solution may still be ideal, with the tables grouped into modules. You might have a file for your Contacts module, a file for your Fixed Assets module, and another for Personnel. It just depends on how complex these modules are. Using modules like this simplifies file maintenance and makes it easier to update or replace an entire module.

This Hub and Spoke design is explained a bit more in the FileMaker Foundations and Migration Methodologies tech brief on filemaker.com.

[flapjacks]

I have converted my 5.5 to 7 and did it all with one file. Ender is correct when I go to 8 I will use seperate files for the various entities. The relationships are particulary difficult to work in with so many tabels. Things which should take a couple of minutes sometimes take quite a bit longer to figure out.

John

[SlimJim]

This topic of one file or many files is receiving a lot of space on various forums and I read all the posts and reach no conclusions (typical!!)

However, I have reached a conclusion about the relationship diagram. It needs to be thought out and from the beginning, a method adopted and then consistently followed. I have been examining a multi-file conversion (FMP3 to FMP7/8) and of course each file has its own diagram with the current file central to that diagram. It has been pointed out elswhere that this perhaps should form the basis of further conversion. So I have tried this. I had already added an interface file with an ad-hoc somewhat chaotic relationship diagram so I decided to create another interface file (isn't it nice to be able to do this with a "live" system and cause no damage) and as far as I am able apply the symmetric rules: each layout is attached to a TO (mandatory) and each TO is attached to a layout (choice). So looking at a particular layout I work out all the TO's that I need for that layout and create them and their relationships. Put them into a "box" and describe what they are doing. A "box" is simply a text box in the relationship diagram which sits in the background layer (using FMP8A). All the boxes are disconnected (choice) and you end up with a very neat looking diagram. Generally it has lots more TOs then the chaotic method but it is very easy to navigate and extend.

(Let me make it very clear that this is not my idea I have read numerous documents so cannot recall who suggested it so failure to quote source is a function of my bad memory not lack of respect)