Click above to get retro games delivered to your door ever month!

  A flat file manager is a piece of software which manages lists. As
  with grocery lists, task lists and birthday party invitation lists,
  you are free to decide what kind of information, and how much of it,
  to store.

  Suppose you want to store invoices in your flat file system. (Don't
  laugh, people have been doing it for centuries.) On each invoice,
  paper or electronic, you'll store the name and address of the customer,
  the date, the items ordered, and the charges.

  Paper invoices have an item section in which you list all the items
  ordered. There might be 20 rows. Should a customer order 23 items,
  you simply grab another invoice and use its first three item rows,
  stapling the two documents together afterward.

  Now, five thousand invoices later, you want the list of people who
  purchased a water distiller from you. How will you produce this list?
  In a paper-based system, you'd haul open a file-drawer and go through
  the invoices one by one. At the end of the day, you'd never be quite
  sure whether you missed one.

  In the electronic flat-file version of this invoicing system, we'd
  create a file containing fields for each bit of information normally
  written onto the paper invoice. For the items area, we'd need several
  "sets" of fields, each set corresponding to a column. We might name
  them similarly, so we could easily recognise them. For example, they
  might have names such as Qty_1, Qty_2, Qty_3, Description_1, Description_2,
  and so on.

  The first problem that emerges is the redundant typing: each time
  a customer places another order, we must type all the customer information
  in again.

  A second difficulty lies in our ability to search the database. We
  can still do it, of course, but to find any item ordered (for example,
  water distillers, we must examine each Description_# field in each
  record). It will certainly be faster than manually going through a
  pile of invoices, and has the advantage of certainty, but it will
  take minutes or hours to produce the list, depending on the size of
  the file.

  Although disk space is quite cheap, our flat-file invoicing system
  positively squanders it. Say, for example, we allow for 20 rows of
  items. Each row requires three or more fields (quantity, description,
  price, extended amount, tax perhaps). Now suppose the vast majority
  of invoices are only for 5 products: the remaining 15 rows (60 fields)
  will sit empty, taking up disk space.

  A simple law of computing is that a small file can be searched more
  quickly than a large file. Therefore, the more we waste disk space,
  the slower will be the system's performance.

  Lastly, we don't want a system which permits duplicate invoice numbers.
  At the same time, as in our paper-based system, we confront the problem
  of the 23-item order. How do we staple two electronic invoices together,
  and at the same time also obey our previous rule of no duplicate invoice
  numbers? Well, we could add a page-number field, and expand our notion
  of duplicates to refer to the combination of invoice and page number.

  As you can see, flat-file systems have several serious failings, when
  the task at hand is something complex such as invoicing. These failings
  gave rise to new storage concepts, and to new database schemas.

  This is not the place to get into hierarchical and network-model database
  structures, since for our purposes here they have purely historical
  interest. We'll move instead directly to the quasi-relational (record-oriented)
  model employed by Clipper.