Record design

Overview

Because of the unique nature of Model 204 records (see record architecture), the translation of a logical design into Model 204 records often includes a great deal of logically related data being included in a single physical record.

For example, take the case of a billing system, where you might consider having separate records for an invoice and then additional records for each of the invoice lines. From a Model 204 perspective, it is more likely that you would have a single record where the invoice lines simply repeat (either as a set of individually managed fields, or as a formal field group.

There are a number of reasons why this approach suits Model 204:

• Because a single read of the record makes all of the information available (think of the data as being pre-joined), performance should be better.
• The factors usually causing the records to be defined piecemeal, notably having issues with variably occurring data, do not exist in Model 204.

What is most important, whether you are implementing a design in Model 204 or in any platform, is to understand the data relationships.

The importance of a good logical design

If you have a good logical design, the record structure almost jumps out at the file manager: data that is logically connected can be efficiently, physically, tied together.

Or, in reverse: if you do not have a good logical design, it is unlikely that you will be able to implement a system that performs well and achieves its objectives.

A unique record key?

Unlike many systems, Model 204 supports records that do not have a unique record key.

But, while it supports it, it is often not a good idea. Perhaps you need to provide reports from the data, or to extract data to feed other systems. You are likely to find that such downstream processes will require uniqueness.

In these just-mentioned cases, using an automatic field such as [[CREATE-TIME can make sure that all records contain a unique key.