• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

Q&A

Q1:Given that storing calculations and indexing fields both affect performance, are there any rules for determining the best choices?
A1: There is one simple rule for optimizing performance: test. You can understand the conceptual difference in storing or calculating a value, but until you actually attempt to use the database file (over a network if necessary), you will not understand the performance impact. Typically, people identify performance “problems” that turn out not to be actual problems when databases are deployed. Use your understanding of issues that may affect performance to guide your stress testing of a database, but in most cases, do your optimization after determining that a problem exists or will soon exist. And always remember that performance issues tend to become visible only after significant amounts of data are stored in the database.
Q2:Are there guidelines for naming fields?
A2: “Meaningful” is the first guideline, and it's amazing how frequently it is ignored or misinterpreted. Wherever possible, use the terminology that users of the system will use; they frequently will see field names as they modify layouts and databases. An apparently small issue such as the description of people served by a social service agency (“patients,” “clients,” “residents,” “users,” and so forth) actually can be a significant issue. Beyond that, try for concise field names without undue abbreviations (“PatientNURM” is rather murky). And, if you're ever going to use ODBC or the Web, try running words together rather than using spaces in field names. And always use the new Comments area in the Fields tab of the Define Database dialog to provide information about your fields.


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint