Linked Fields

As you consider the creation of  database tables through the creation of templates,  think about optimizing the database design by eliminating data redundancy.  This can be achieved with linked fields while shielding the user from the intricacies of the design of the relational database.

The source of linked data can only be a Global Template. More than one linked field can be brought into a General Data (Global or Subledger) Template from the same source. Frequently repeated items (such as city of residence in a Name table, where the same city may apply to most of the customers) can be moved into one table (e.g. a City template ), and linked from that table into those tables that make use of them e.g.

a Global Province/State/Country table linked to
a Global City table linked to
a Global Name & Address table linked to
a Subledger - Accounts Receivable table and also linked to
a Subledger - Accounts Payable table.

Linked fields also provide a convenient way of centralizing and instantly distributing changes in data throughout the database. For example, a change in the cost of an inventory item can take effect in all tables that reference this item, if the inventory record including the amount field is linked into those tables. Linked fields can also be brought into a General Data Template from more than one source table.

Links can also be inherited through the hierarchy of templates. That is, the Name template can itself serve as a source for other templates that make use of its fields. In this case, the native fields of the Name template will become the links of the first order, while the linked fields (City, State,  and Country) will be the links of the second order (if brought into those templates). STEP FORWARD will hide the real origin and nature of the linked fields from the recipient templates, posing them as native fields in the source, regardless of their true location.

However, the user should realize that multi-level linking of fields from one template into another, while providing a smooth flow of data, can tax the database server to the point where searches on the tables with links become increasingly slow. The exact threshold of the number of individual links within the template and the level of nesting of links, where the loss of performance becomes noticeable, depends on the design of the particular hierarchy of templates/links, and will vary from one RDBMS to another. As a rough rule, the flatter the structure of the links (i.e. the fewer levels of reference) the better is the performance.


Go to:
Table of Contents
Global Template - Topics of Interest
Subledger Template - Topics of Interest
Transaction Template - Topics of Interest