Although you can create the table interactively without any forethought, carefully planning a data-
base system is a good idea. You can make any changes later, but doing so wastes time; generally,
the result is a system that is harder to maintain than one that is well planned from the beginning.
Before you get started, you should understand the table design process.
In the following sections, we’ll be exploring the new, blank table added by Access as the new data-
base was created. It’s important to understand the steps required to add new tables to an Access
database. Because the steps required to add tables have changed so dramatically from earlier ver-
sions of Access, even experienced Access developers will want to read the following sections.
The importance of naming conventions
As your databases grow in size and complexity, the need to establish a naming convention for the
objects in your databases increases. As you already know, changes to the name of an object are not
propagated throughout the database. Even with the
Name AutoCorrect
option turned on (Office
button
.
Access Options
.
Current Database
.
Name AutoCorrect Options), Access only cor-
rects the most obvious name changes. Changing the name of a table breaks virtually every query,
form, and report that uses the information from that table. Your best defense is to adopt reasonable
object names and use a naming convention early on as you begin building Access databases and to
stick with the naming convention throughout the project.
Access imposes very few restrictions on the names assigned to database objects. Therefore, it is
entirely possible to have two distinctly different objects (for instance, a form and a report, or a
table and a macro) with the same name. (You can’t, however, have a table and a query with the
same name, because tables and queries occupy the same namespace in the database.)
Although simple names like Contacts and Orders are adequate, as a database grows in size and
complexity you may become confused about which object a particular name refers to. For instance,
later in this book, you’ll read about manipulating database objects through code and macros.
When working with Visual Basic for Applications (VBA), the programming language built into
Access 2007, there must be no ambiguity or confusion between referenced objects. Having both a
form and a report named Contacts might be confusing to you
or
your code.
The simplest naming convention is to prefix object names with a three- or four-character string
indicating the type of object carrying the name. Using this convention, tables are prefixed with
tbl
and queries with
qry
.
The prefix for forms, reports, macros, and modules are
frm
,
rpt
,
mcr
,
and
bas
or
mod
,
respectively.
In this book, most compound object names appear in mixed case:
tblBookOrders
,
tblBookOrderDetails
, and so on. Most people find mixed-case names easier to read and
remember than names that appear in all-uppercase or all-lowercase characters (such as
TBLBOOKORDERS
or
tblbookorderdetails
).
Also, at times, we’ll use informal references for database objects. For instance, the formal name of
the table containing contact information in the previous examples is
tblContacts
. An informal
reference to this table might be “the contacts table."
36
Access Building Blocks
Part I
06_046732 ch02.qxp 11/21/06 8:46 AM Page 36
|
|