July 7, 201015 yr I am a self-taught filemaker user who has recently made the move to sharing a database over the internet, and I have only now discovered how important it can be to make speed-conscious choices in how one defines tables and constructs layouts. I have many unstored calculations, and I understand that I can improve speed significantly by having fewer of these. A fair number of these calculations I use specifically in scripts but don't actually ever need to display in layouts. Am I right in thinking that the speed issue isn't really about whether one has a lot of unstored calculations in one's tables but about whether one places them on layouts that get invoked in the course of using the database? So while I recognize that I can replace field references to unstored calculations in my scripts by direct calculations (and thus allow me to cut the calculations from my tables), I don't want to rewrite all of my code if that is unnecessary. Moreover, since defining the calculations within my script will sometimes involve temporarily changing context, it seems to me that referring to an unstored calculation in a table offers a more elegant solution because the messy business of temporarily switching context will be taken care of by Filemaker. It certainly would be easier to leave my scripts and my table definitions as they are, and to pare back those of my layouts that get invoked by scripts to a bare minimum of fields (maybe even just the serial number of the table's key.) Is my thinking correct? Can I just leave the unstored calculations as they are and pare back my layouts? Or is there any danger in doing so that I haven't yet anticipated. Any help on this fundamental database design question will be much appreciated.
Create an account or sign in to comment