A relatively simple database
system in which each database is contained in a single table.
Designing a flat file database
is a relatively straightforward procedure. Since you can't
share information between files in a true flat file database,
everything you want to track in your database needs to have
a field defined for it.
For example, if you have a
file named Invoices and you want to include customer information,
you need to define fields for customer name, address, city,
state, and postcode. These fields will be in addition to
the fields you may have already defined in the Invoices file.
If you want to include product information, you need to define
fields for product name, color, size (or other attributes),
and price. As you can see, your flat file database can contain
a large number of fields and in many cases a lot of duplicate
data, such as customer or product names.
Designing a flat file database
is simply a matter of deciding what data you want to track
and creating a field for each piece of data. However, Flat
File systems have their problems.
Problem: You
store the same information in several places, such as: Customer
Names, Product Information, Order and Invoice Information.
Suppose you have to change some of the data e.g. product
name supplied to customers.
When you update these items,
it is time consuming to find all of the places they occur
and then type in the same information repeatedly. How can
you be completely sure that all customer records are the
same?
