Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Field Naming Conventions

The naming conventions for tables with regard to spaces, characters, capitalization, and so forth apply also to fields. There are some additional considerations when it comes to naming fields. Specifically, they have to do with the identification of field types and the naming of internally used fields.

Many developers use abbreviations for data types in field names. Often it’s handy to know the data type of a given field when working with it without having to refer to the Manage Database dialog. Here we’ve used “t” for text, “n” for number, and “c” for calculation:

  • ProductName_t

  • Price_n

  • TaxRate_n

  • Tax_c

Some developers also note whether a field is indexed (“x” for indexed, “n” for unindexed):

  • Location_Name_tx

  • Location_Desc_tn

  • Location_Size_nn

Some naming conventions also break out a division between data fields and what are commonly referred to as developer fields—those fields that you need only to make your FileMaker Pro solution work. If you ever went to import your database wholesale into another system, you would probably leave behind the developer fields. Here, we have two abbreviations: “k” for key (or match field) and “zz” (so that it sorts to the bottom of the list) for developer utility fields. We also use underscores to ensure that keys sort to the top of our field list, with the primary key coming first.

To understand how keys are used to identify records in tables and form relationships, see Chapter 5, “Relational Database Design,” p. 143.


  • __kp_primary_AlbumID

  • _kf_foreign_ArtistID

  • AlbumName

  • Date

  • zz_SelectedPortalRow

  • zz_UserColor_Preference

  • zz_UserGenre_Preference

Many developers use a minimal set of field-naming standards. It relies on leading lowercase characters to indicate the field type. If you choose to use that minimal set, here are the conventions used:

  • g—Global

  • c—Calculation

  • s—Summary

  • zz—Internal use (This causes the field name, when shown in an alphabetical list, to be at the bottom. If you use a single “z,” your internal fields will be interspersed with fields such as ZIP code.)

Descriptions of field types might or might not use this set of standards, which you can add to the end of the field name following an underscore:

  • t—Text

  • n—Number

  • d—Date

  • ts—Timestamp

  • tm—Time

  • c—Container

Putting these together, you could have field names such as these:

  • creationDate_d

  • gProcessingOffice_t

  • gcNextInvoiceNumber_n

You can even go further by not bothering with field types where the field name already includes it. creationDate_d really adds no information to creationDate.

Whatever you do, be consistent. The point is not to create a set of naming conventions that overshadows the database but, rather, to create naming conventions that help you and future developers build and maintain the solution.

Tip

Don’t imagine that all the fields on your Relationships Graph will adhere to these naming conventions. You control your own fields, but as you begin to use external data sources, you will be incorporating fields from other databases. You can have a field called payrollDate_d in your own table, but if you are relating it to a field called datePaid in the corporate database, chances are slim that the database administrator will want to rename the field to make it consistent. The ProjectID field in your database might be related to a field that is called JobNumber in another FileMaker database that you do not control. And, in a global world, the external data source names might just be in another language. Be as clear and consistent as you can, but do not assume that you can control the names of fields in other databases. (In general, the owner of the Payroll database wins out.)


If you’re planning on using FileMaker Pro as a web back end, refer to “Problematic Field Names” in the “Troubleshooting” section at the end of this chapter.


For more information on using databases on the Web, see “Designing for IWP Deployment,” p. 532, as well as Chapter 25, “Custom Web Publishing with XML/XSLT,” p. 545.


  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint