What is wise to do with tables in FMP7?

[Jukkie]

Hello

I have 3 databases called:

Relations.fp5 -> using a extra database contactpersons.fp5

Orders.fp5 -> using 2 other databases

Invoices.fp5 -> using 1 other database

Now I am rebuilding my solutions in FMP7, but what is wise to do.

Combine my multiple databases in one database using tables.

Or

Keep the databases separated and use only tables for the direct linked databases like: Relations.fp5 gets a table called Contactpersons.fp5

Are there any rules about how to use tables within FMP7? What is the limit?

Greetings

Jukkie

[Fitch]

You don't have to combine any of your files if you don't want to do so. There may be valid reasons for keeping them separate (such as: it works fine the way it is). But combining some or all of them into one is a great way to learn FileMaker 7! The limit on tables per file is 1,000,000. Your relationship graph will become unusable well before you get anywhere near that point. There really are no "rules" but there are guidelines for database design that many of us try to follow.

The "Separation Model" discussed in this forum is not so much about keeping "entities" in separate files (e.g. Invoices, Orders) as it is keeping all your raw data in one file (with as many tables as required) and then building an "interface" file that has NO data at all, but contains all the layouts and script and relationships that interact with the data file. The big advantage of this is that it makes updates a breeze -- no more data imports, just drop in a new interface file.

[T-Square]

I think that limiting the number of files that are opened at the operating system level is of vital importance--especially in a networked situation. Most of the support calls I have taken from clients using my FM6 applications were because corruption of data files and relationships resulted when their LAN crashed. FM6 has the lamentable practice of tanking relationships between your tables (files) when the OS flakes out, which appears to clients as if it has erased data. Moreover, when the relationship is fried and your client fires up a database that scripts anything in the related table, your client is mysteriously (to them, at least) asked to locate the destination file, which they may or may not do correctly. If they pick wrong, then any part of your database that relies on that relationship (scripts, calculations, etc.) also gets corrupted, and you have a royal mess on your hands.

That was why I was so excited to see FM7 support multiple tables in a single OS file, and I made the considerable effort to implement the separation model in the new version. So far, I have seen none of the kinds of corruption that I used to get (6 months down the road now).

HTH,

David

[Ender]

On the flip side of this, if you have everything combined into one file, then maintenance for large solutions can be a more daunting task: