| Getting Started Building ColdFusion MX Applications |
|
|
Preparing to Build the Sample Application |
|
| Getting Started Building ColdFusion MX Applications |
|
|
Preparing to Build the Sample Application |
|
After you identify the information to collect, you must consider where to store the data. Prior to creating the data collection form and instructing ColdFusion where to store the form data, you must have a database ready to accept the data.
If you had to create the Compass Travel database, you would create a table named Trips to store the information that you plan to collect about each trip. The table would look something like this:
Each field in the Trips table has a data type attribute that describes the type of data that can be stored in the column. For instance, the tripName column can contain text data while the price column can only contain numeric data. It is important to know what type of data is valid for each column so that your data collection forms can validate against incorrect values entered by the user.
Looking closer, you might wonder why the eventType column is a number and not a text data type column. Recall that data requirements analysis identified the need for a type of event (surfing, mountain climbing, kayaking, and so on). The purpose of this column is to classify trips into various categories based on the trip activity. It is essential that the application classifies the trips consistently. Therefore, it is important to offer a list of event types for the user to select, rather than to accept free text input.
To present a list of event types for user selection, the event types are stored in a separate table, the Eventtypes table. This table is already populated and contains the following rows:
When the user selects an event type from the list obtained from reading the eventtypes table, the correct event type must be saved to the trips table with all the other trip related data. The application could store the eventType (for example, mountain climbing) itself into the eventType column in the Trips table. But if the name Mountain Climbing were later shortened to Climbing in the eventtypes table, new mountain climbing trips would be classified differently than ones saved before the change. For this reason and to save space in the database, the key to the eventtypes row (eventTypeID) is stored in the trips table instead.
The two tables are said to have a relationship. This relationship works by matching data in key fields. In this case, the matching fields consist of a primary key (eventTypeID) from the Eventtypes table, which provides a unique identifier for each record, and a foreign key (eventType) in the Trips table. The foreign key contains the same value as the primary key, pointing to a unique event type. The following figure shows this relationship:
