Record design: Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 1: Line 1:
==Overview==
==Overview==
<p>
Because of the unique nature of Model 204 records (see [[Record (File architecture)|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. </p>


<p>Because of the unique nature of Model 204 Records (see [[Record (File architecture)|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. </p>
<p>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 (File architecture)|field group]].</p>


<p>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 (File architecture)|field group]].</p>
<p>There are a number of reasons why this approach suits Model 204:</p>    


<p>There are a number of reasons why this approach suits Model 204:</p>    
<ul>
<li>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. </li>


* 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
<li>The factors usually causing the records to be defined piecemeal, notably having issues with variably occurring data, do not exist in Model 204. </li>
* the factors usually causing the records to be defined piecemeal, notably having issues with variably occurring data, do not exist in Model 204.
</ul>
   
   
<p>The most important thing, regardless of whether you are implementing a design in Model 204 or any platform, is to understand the data relationships.</p>
<p>What is most important, whether you are implementing a design in Model 204 or in any platform, is to understand the data relationships.</p>


==The importance of a good logical design==
==The importance of a good logical design==
<p>
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.</p>


<p>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.</p>
<p>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.</p>
 
<p>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.</p>


==A unique record key?==
==A unique record key?==
<p>
Unlike many systems, Model 204 supports records that do not have a unique record key.</p>


<p>Unlike many systems, Model 204 will support records without a unique record key.</p>
<p>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.</p>
 
<p>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.</p>
 
<p>Consider, in such cases, of using an [[Field design (File management)|automatic field]] such as the CREATE-TIME to make sure that all records contain a unique key.</p>
 
 
 
 
 


<p>In these just-mentioned cases, using an [[Field design (File management)|automatic field]] such as <var>[[CREATE-TIME</var> can make sure that all records contain a unique key.</p>


[[Category:File management]]
[[Category:File management]]

Revision as of 00:51, 5 March 2014

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.