5. Features of flat file database

Placing data in a flat file database has the following advantages

• All records are stored in one place
• Easy to set up using a number of standard office applications
• Easy to understand
• Simple sorting of records can be carried out
• Record can be viewed or extracted on the basis of simple criteria

Everyday things like business contacts, customer lists and so on can be stored and used in a flat file database.

But they do have some serious disadvantages when it comes to more than a few thousand records. Consider the flat file table you saw earlier

1. Potential duplication. As more and more records are added to the database it becomes difficult to avoid duplicate records. This is because there is no mechanism built in to the system to prevent duplication. Later you will see how 'primary keys' are used to prevent this.

2. Non-unique records. Notice that Mr & Mrs Jones have identical ID's. This is because the person producing this database decided they may want to sort on identical telephone numbers and so has applied identical ID to the two records. This is fine for that purpose, but suppose you only wanted to extract Mrs Jones' record. Now it is much more difficult.

3. Harder to update. Suppose that this flat file database also stored their work place details - this will result in multiple records for each person. Again, this is fine - but suppose Sandra Jones now wanted to be known as 'Sandra Thompson' after re-marrying? This will have to be done over potentially many records and so flat file updates are more error-prone than other methods

4. Inherently inefficient. Consider a situation where the database now needs to hold an extra field to hold their email address. If there are tens of thousands of records, there may be many people having no email address, but each record in a flat file database has to have the same fields, whether they are used or not. Other methods avoid this wasted storage.

5. Harder to change data format. Suppose the telephone numbers now have to have a dash between the area code and the rest of the number, like this 0223-44033. Adding that extra dash over tens of thousands of records would be a significant task in a flat file database.

6. Poor at complex queries. If we wanted to find all records with a specific telephone number, this is a simple single-field criteria that a flat file can easily deal with. But now suppose we wanted all people living in Hull who share the same surname and similar postcode? - the criteria can quickly become too complex for a flat file to manage.

7. Poor at limiting access. Suppose this flat file database held a confidential field in each record that only certain staff are allowed to see - perhaps salaries. This is difficult to achieve in a flat file database - once a person has entered a valid password to gain access, that person is able to see everything.

Because of these limitations other types of database have been developed. The next few pages will describe these and their features.