I'm building a solution which will hold millions of records on about 3 or four tables. 2 of those tables will have fields that hold "static" data that should never change once its created. Then there will be a number of fields on those 2 tables which should be constantly changing (classification, performance and quality checks for "static" data). Would it make sense, specially from a backup point of view, to separate those fields into one to one tables?

It would only make sense from a backup point of view if you split those fields into separate tables in separate files. FileMaker Server can decide to create a hard-link using an older copy of a file if the current version hasn't changed since the older backup, but this happens on the file level, not the table level.

The only possible benefit that I could imagine is with indexing. If you wanted to use indexes on the fields that dont change and possibly not use indexes on the ones that do, you may get some performance benefits from it since you would not have to update all those indexes on deletes, updates, etc.

jbante: Yes, it would definitely be at the file level.

 

mr_vodka: some of the fields that DO change need indexing, hence why I brought this up.