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, if you consider a billing system, where you might consider having separate records for an invoice, and then additional records for each of the invoice lines, for 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.
The most important thing, regardless of whether you are implementing a design in Model 204 or 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 should almost jump out at the file manager: tying data which is logically connected can be efficiently, physically, tied together.
Perhaps this should be thought of in reverse: if you do not have a good logical design, it is unlikely that you will be able to implement a system which performs well and achieves its objectives.
A unique record key?
Unlike many systems, Model 204 will support records without a unique record key.
But, while it supports it, it is often not a good idea. Perhaps you need to provide reports off of the data, or extract data to feed other systems. You are likely to find that such downstream processes will require uniqueness.
Consider, in such cases, of using an automatic field such as the CREATE-TIME to make sure that all records contain a unique key.