I put this on my website a long time ago, maybe around 1995, as an HTML page. This is it moved to my blog.
Introduction
FileMaker is a relatively low-powered database program whose primary advantage is its ease of use. Compared to more ‘standard’ client-server database systems, solutions can be created very quickly. And because FileMaker focuses on a higher level of abstraction, these solutions have less unnecessary complexity and obscurity. These are serious advantages, because almost every system will need to be seriously rethought (‘refactored’) at some point in its development.
However, it is not, as claimed, fully relational, and it does not allow code reuse. These disadvantages can lead eventually to overstretched and disorganised systems. If you use FileMaker you should recognise these limitations.
The FileMaker Trap…
People get off the ground quickly with FileMaker. But often with uninformed confidence they add complication, redundancy and duplication until they are no longer able to predict the consequences of any more changes. The company’s administration may become led by the eccentricities of their system. Employees may be so confused by the bizarre sequence of actions which they perform that they no longer have any insight into their role in the business. This is not productive.
Developers do not just need technical skills, they must understand how to deal with complication itself. If you do not recognise and manage complexity it will eventually overwhelm you.
…And How To Avoid It
By using a little discipline from the start you can postpone the point at which the system becomes too complicated to develop further. If you are disciplined enough then you can postpone it indefinitely.
Self -Documentation
It is impossible to completely document a system which is continually being developed. Denying these facts can lead to confusion and cover-ups. The only way to ensure that a system’s design and operation can be understood is to:
- Explain the general principles of your design, the principles behind its major components and any unusual techniques employed.
- Use methods such as those below to make the interdependencies in your system obvious.
Scripts
Use prefixes to indicate how the script is used. For instance:
BUTTON.Invoice Details SUB.Log Print Date
Rearrange the script list so the BUTTONs are grouped together appropriately. Use empty
scripts to divide scripts into groups.
Fields
Indicate the source of a lookup or reference by prefixing the field name with the
source. For instance:
Customers..Name Customers..Address
If a field is calculated from another field, indicate this in the field name. For instance:
Order Date Order Date.Year
Strive to identify distinct groupings of fields and identify them by giving all the
fields a prefix. For instance:
Car.Model Car.Registration
These techniques will group the fields together when using the standard alphabetical view, making the database structure far more obvious.
Remove Garbage
It is essential to remove any unused part of a system. In the ongoing development of a system, parts will inevitably be discarded. It it important to remove these from the system. In general, they will not have any impact on performance, but their presence implies that they are still relevant to the whole. At least mark them as unused. Otherwise they are a smoke-screen to anybody trying to understand the system.
Unused Fields
Do not delete unused fields because that would affect any scripted import orders. Rename them with a z. prefix so that they show up at the bottom of the list and turn off their indexing. When adding fields in future you may simply rename these fields and redefine them.
N.B. Use the Overview in the Password sub-menu to see which layouts a field is on.
Unused Scripts
FileMaker will not warn you when deleting scripts which are used by other scripts. Using the above script name prefixes will help in determining a script’s dependencies. Instead of immediately deleting a script, mark it with a prefix of UNUSED. and insert a Show Message script at the start. After some time, if this script has not displayed its presence, you may delete it.
White Space in Calculations
Use spaces and returns to make your calculations readable. Show nested IFs like so.
IF(test1; Â resultA; Â IF(test2; Â Â resultB1; Â Â resultB2 Â ) )
The results should be indented by 1 more space than the IF and the ). Similar methods can be employed for Choose() and Case() statements. This should be second-nature to C or Java programmers.