When and how to split up a large file

[cpbatwes]

I've heard many FM developers recommend splitting up a file that has over a few hundred fields. I'd love help (I really just have 2 questions) on how to do this per the following example:

BACKGROUND

The file is called "People.fp5" and has 450 fields, mostly attributes about the people (just bare with me, I know it sounds strange).

1) WILL FINDING BE SLOWER - If I put some of these attributes in another file and create a 1:1 relationship so that the person's name is still stored in people.fp5 but their race, gender, and birthday are stored in demographics.fp5 and linked by the person's uniqueID, WILL FINDING BE SLOWER?? Say I want to find all people records that are gender=male. Would I just slap all the demographics.fp5 fields on a find layout in the people.fp5 file and search for gender=male? But when there are 100,000 plus records, will finding be manageable since it's looking in a related file?

2) FILE CRASHING - I'm having trouble with a large file that I can't rebuild - took too much time to get it here - that it works fine, but half the time I try to delete a field I don't need the whole file crashes. What's the best way to carefully split up this file?

Thank you!

Chris

[John Caballero]

This doesn't sound like a file that I would split. Yes, finding will be slower because you're seaching through a relationship.

A good rule of thumb in determining if you should create a related file is this:

Is there record duplication? If I wanted to create a database of people and their CD collections, I could put all the information into a single file, but for each CD entry, I'd have to specify the User information. At that point I'm creating a lot of duplication.

In your file do you have multiple entries for the same person?

[cpbatwes]

Thanks - any idea how much slower with the following: With 30K records in the main file and the related file, and a 1 to 1 relation b/c the related file is just attributes of the main file's entity?