The information stored in a database is organized into records and fields. Each field contains a specific category of information — names, phone numbers, birthdates, etc. Your first task after creating a new database is to decide how many and what fields are needed to get the job done. It’s somewhat like designing a house — you have to decide what the best configuration is. How many bedrooms you need? How many baths? Will you need an office? And just like architecture, there are sometimes trade-offs that have to be made in designing a database.

For some database jobs it is extremely obvious how the fields should be set up. But usually you have more flexibility than you might think. Take a simple name and address list, probably one of the most basic database applications. How should the name be stored? All in one field? Or should there be separate fields for first and last names? What about Mr./Ms./Mrs., should that be in a separate field? There are no hard and fast answers — it depends on how you want to use the database. For this example (names), data entry will probably be easier if you use a single field. On the other hand, you’ll have more options for organizing and formatting if you split the name into several fields. The choice is up to you.

One thing to keep in mind is that if you make a mistake, it is much easier to combine two fields together than it is to split a single field into two. For example, it is quite easy to take separate first and last name fields and combine them, but if you type the names into a single field it could be quite difficult to later split them apart. If you have any doubt, it is better to err on the side of separating the data into more fields. You can add new fields, remove fields, or change the properties of fields at any time, even after you’ve filled the database with data. Once you start entering data, however, it can be more work to re-arrange the fields. Some extra planning before you start entering data can pay big dividends in the long run.


See Also


History

VersionStatusNotes
10.0No ChangeCarried over from Panorama 6.0