Record design - Revision history

ELowell at 17:02, 12 May 2014

2014-05-12T17:02:54Z

← Older revision		Revision as of 17:02, 12 May 2014
Line 27:		Line 27:
	<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 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>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>		<p>In these just-mentioned cases, using an [[Field design\|automatic field]] such as <var>CREATE-TIME</var> can make sure that all records contain a unique key.</p>

	[[Category:Model 204 files]]		[[Category:Model 204 files]]

Dme: Dme moved page Record design (File management) to Record design

2014-05-10T05:05:00Z

Dme moved page Record design (File management) to Record design

← Older revision	Revision as of 05:05, 10 May 2014
(No difference)

DmeWiccan: Automatically generated page update

2014-05-09T22:45:54Z

Automatically generated page update

← Older revision		Revision as of 22:45, 9 May 2014
Line 29:		Line 29:
	<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>		<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:Model 204 files]]

Admin: /* A unique record key? */

2014-03-05T00:51:50Z

A unique record key?

← Older revision		Revision as of 00:51, 5 March 2014
Line 27:		Line 27:
	<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 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>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>		<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]]

Admin at 00:51, 5 March 2014

2014-03-05T00:51:35Z

← Older revision		Revision as of 00:51, 5 March 2014
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]]

Admin at 22:09, 18 December 2013

2013-12-18T22:09:59Z

← Older revision		Revision as of 22:09, 18 December 2013
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, 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>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>

Admin at 21:54, 18 December 2013

2013-12-18T21:54:44Z

← Older revision		Revision as of 21:54, 18 December 2013
Line 3:		Line 3:
	<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, 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>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>

ELowell at 20:10, 16 December 2013

2013-12-16T20:10:22Z

← Older revision		Revision as of 20:10, 16 December 2013
Line 24:		Line 24:
	<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>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>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>

Admin: Admin moved page Record Design (File management) to Record design (File management) without leaving a redirect

2013-12-12T00:09:30Z

Admin moved page Record Design (File management) to Record design (File management) without leaving a redirect

← Older revision	Revision as of 00:09, 12 December 2013
(No difference)

ELowell: /* A unique record key? */

2013-08-29T15:53:23Z

A unique record key?

← Older revision		Revision as of 15:53, 29 August 2013
Line 22:		Line 22:
	<p>Unlike many systems, Model 204 will support records without 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 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>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>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>