Just out of curiosity, to what purpose is the goal of reducing the size? Are you trying to improve performance? Do you have limited disk space? Are your backups taking too long?
We really would need to know more about your setup and your end state goals to lend meaningful advice.
It depends on how the layouts are setup. If each layout has inserted graphics then each layout takes up space. If they use a global field for graphics (say a logo) then the layouts take up little space. Scripts also do not take up much space.
As Mike mentions, reducing size is different than improving performance.
There is a certain amount you can do to optimize layouts. In FM 13, you can go through layouts and make sure as much as possible that they are taking advantage of styles and themes. This reduces the amount of CSS information that needs to be stored.
It is more likely that images placed on layouts take up a lot of file size as well, so you can review those as well and see if you can optimize that by using globals or styles to display images. That way you only need to store one copy of an image in your file, and reference it everywhere it is used.
As for fields, apart from container fields, indexing takes up the most space, so you can pay attention to how that is configured for fields.
Relationships don't add much in terms of file size, calculations can, depending on their indexing as I mentioned.
This doesn't take into account other performance issues, but only related to file size, since you asked
Hope this helps some.
I am not sure this is right. At a technical presentation (At FileMaker UK) I thought an engineer said they optomised image storage in layouts by checking a hash of the image, if the has matched then the origional was referenced.
Field index settings. An index takes a up a lot of space; but you need them. Quite often the indexing for a field is turned on when it can be disabled. You have to proceed carefully though. Fields involved in relationships or things you want to be able to search on need an index but you might find that there are many you can delete the index for - how often do you search on a phone, fax or extension number, saluations, etc.
In FM13, if you've changed themes you'll end up with a lot of extra CSS in the background.
You'll also need to do a "Save A Copy" to see the results.
As Mike said, reducing file size is very different from improving performance.
If the same image is used over and over and not set as a global field than maybe it does optimize ( I have not bothered verifying this as a global field is better for developing purposes).
That said, this persons database could have different images on each layout. I really do not know. If you are quickly trying to reduce file size and need all the records, and possibly need every layout, then the images and containers are the best place to start.
Store containers externally and reference them, set logo's and images that are required on most layouts as a global field is the first way to reduce file size.
If you use the same image on multiple layouts, it downloads only once from the server. This is good for performance.
I do not know what that does to file size, however. (Which, of course, goes back to the original point. File size =/= performance.)
Cool, there are a few goals
1. I want to improve performance
2. I want to reduce size
3. I want this database to be far more simple for myself to navigate
There is just far too much rubbish in it, 100's of redundant unused calculation fields etc
Removed 200 layouts already
If you're looking at removing unnecessary items look at Base Elements from Goya. Lots of reports there to help.
Keep in mind that unstored calculations and summary fields take up almost no room at all. Indexed fields with lots of data take up a lot of room. If size is paramount, unindex all of your fields and things will get a lot smaller and performance will be degrade a lot. But index management can be important to not index fields that don't need it or that benefit very little from indexing. Obviously container fields are going to make things huge, but you can reduce the size of the file a lot by using remote container storage so that the containers are stored outside of the file. This will improve performance too. Using remote container storage can make the database file a lot smaller, the overall size on the hard drive won't be any less.
Do some experimentation. Save a Copy of the file compressed and see if that makes a difference. Take a copy and delete all of your layouts and see if it makes a huge difference in size. If so, then you know that there are a lot of graphics and things in layouts that you may want to reduce in size. For example, don't import at 600 dpi logo for a layout that is going to be viewed only. But then again, if you are going to print from a layout that goes to a high resolution printer, you may want it. You have to evaluate all of these things and realize how they impact sizes of layouts. Also, take copies of the file and randomly delete some of the tables and see how it impacts the size of the file. It is a trial and error process.
And, as David Zakary says, check out analysis tools like Base Elements, FMDiff, or InspectorPro.
Regarding field indices, if you are using Quick Find on any layouts, make sure to mark only those fields you want to search as "Include field for Quick Find" (see Inspector, "Data" tab, "Behavior" section).
Cool, there was a massive data dump which had 22 million records, i've now changed it to analyse through scribe so nothing has to be imported
have reduced the layouts from over 1000 down to 460
have taken all container data and made it external
next i'm going to smash through the relationship graph!
It is a lot of work, but shoulud make a lot of performance difference too. When working on the relationship graph, try to find relationships that are only used once and can be handled with ExecuteSQL instead of a join to minimize the number of table occurrences. It would be interesting if you have a before and after comparison like how long it takes to open or how long it takes to run a long report or import, etc.