Separation Performance

[Garry Claridge]

Does anybody have any advice on performance penalities using the Seraration Model?

The database I am thinking about has about 80 files/tables with around 50,000 records in some of the tables. It has very complex relationships, this is a database which has been converted from FM 6. I intend to combine the files/tables into one file, this should relieve some of the overhead of the complex relationships.

Thank you.

Garry

[Matthew F]

Hi Garry,

I don't have any real data on this but I haven't noticed anything obvious in the speed of FM7 when using related tables within a file or linked in a second file.

The bigger question in my mind is whether you really want the added work of separating your data from you layouts and business logic. I'm sure you're aware of the benefits of being able to manipulate layouts without messing with your data files and taking your project off line. However there is a signficant price to pay in terms of design complexity. If you frequently add new data fields to your solution then you'll need to take your solution off line anyhow for this purpose. Also all of the new data fields need to be replicated in your business logic file, which is cumbersome.

In your case you might find it difficult or undesirable to fold so many tables into a single data file and a single layout file. This means you may need to navigate from one layout file to another. However the "go to related record" script step will not work in this case since the related record will be the data file not the other layout file. You'll need to create a work around everytime you hop from one layout file to another.

[xtrim]

Mfero is right....if you are only using portals...

If in the gui file you also keep the same tables as in the data file but only with one field - the mainKey field, then you don't need complex calculation...and the "goto related record" will work if you have a good design ;-)