Record design: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
<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 data | ==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 data. </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 fields, or as a formal [[Repeating Field Group (File Architecture)|Repeating Field Group]] (RFG).</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 fields, or as a formal [[Repeating Field Group (File Architecture)|Repeating Field Group]] (RFG).</p> | ||
| Line 8: | Line 10: | ||
* the factors usually causing the records to be defined piecemeal, notably having issues with variably occurring data, do not exist in Model 204. | * the factors usually causing the records to be defined piecemeal, notably having issues with variably occurring data, do not exist in Model 204. | ||
<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> | |||
==The importance of a good logical design== | |||
<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> | |||
==A unique record key== | |||
<p> | <p>Unlike many systems, Model 204 will support records with duplicate record keys.</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 | |||
==Fields and Fieldgroups== | |||
[[Category:File management]] | [[Category:File management]] | ||
Revision as of 21:48, 8 May 2013
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 data.
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 fields, or as a formal Repeating Field Group (RFG).
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.
A unique record key
Unlike many systems, Model 204 will support records with duplicate record keys.
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