The Jacana (Home)
About us




Top of page
6. What is the significance of Subset groups with regard to performance?

Subset groups are OPEN/DB's way of representing one-to-many relationships between sets of data within the structure of the Subset. Each group may include fields from a number of files linked together as one-to-one and may also include one or more "Derived fields". However, each one-to-many relationship will start a new group - a new "node" of the Subset. 

The Subset Group is affected by the record Subset groups allow OPEN/DB to retrieve data using the relational structures designed into your database. In most situations, this approach offers performance benefits over the creation of large join files. Take, for example, an "Orders" Subset containing Order header and Order detail files. 

To select all orders for a given customer, OPEN/DB has to read only the order header records. Only when it finds a match does OPEN/DB need to read the associated order detail records. It is for these reasons, amongst others, that we recommend a "top-down" approach to building Subsets in most cases.


Top of page
7. What is "node" logic and does it affect performance?

Subset "nodes" are directly related to Subset groups. Each file linked as one-to-many becomes a Subset node as well as being the base-file for a new group. As such, it is treated by OPEN/DB as a potential "based-on" file for a given report. This means that, for any report NOT using fields from higher level groups, OPEN/DB can adapt the Subset structure to use the node file as the "based-on" file just for that report. This eliminates the overhead of processing the higher-level files in the Subset if they are not required for a particular report.

For example, consider an order Subset where the Order Header file is the based-on-file and the Order Details file is linked to it as one-to-many. As the based-on file, OPEN/DB treats the Order Header file as a node. The Order Detail file, because it is linked from Order Header in a one-to-many relationship, is also a node. For reports using only fields available from the order detail group, OPEN/DB can create report programs that exclude the order header file. Processing the order header file is unnecessary for these reports, and OPEN/DB's "node" logic enable the pre-compiler to automatically eliminate this overhead even though the Order Header file is the "based-on" file for the Subset. 

OPEN/DB's node logic allows the design of fewer, but more flexible, Subsets secure in the knowledge that OPEN/DB will ensure that reports process only those data necessary. Node logic is yet another reason for designing Subsets with a "top-down" approach because it is only available where you define one-to-many relationship. 

Note that the benefits of node logic are only available if the correct fields are chose when designing the report. Equally, node logic is easily defeated inadvertently by choosing and using the wrong fields in a report . 

Correct use of user views can help to ensure that correct fields are used by report designers and the benefits of node logic will automatically flow from this.


Top of page
8. In my Subset, I need one field from a file which has 30 fields. If I link this file to my Subset, there will be 29 fields there that I don't want. What should I do ?

If you omit this file from the Subset it will be simplified by having fewer fields. The creation and maintenance effort for the user views is similarly reduced. The size of EVERY program which uses this group is reduced (a possible performance factor). If the file has 30 fields, but your Subset needs only one of these, you can leave the file out of the Subset design and evaluate the field as a derived field using a user written I/O module. The internal processing overhead is reduced to the tune of approximately 200 fewer HLL program instructions for every record read at this level of the Subset hierarchy (ie. if the average execution of a report on this Subset (using this file in two links) might expect to process 5,000 records for this group, then the program will execute approximately 1 million fewer HLL program instructions. The size and efficiency of every program that reads this file is improved by up to this margin. The time to load the Subset (when this is necessary from time to time) is reduced. 

Solution 1 - An I/O module 

You can write a simple re-entrant I/O program to process this file. Then, create derived fields for those fields from the file that you require and use the logic to invoke your I/O module to return values for fields. The major advantage of this methodology is the insulation of the Subset, and all its reports, from the database in this file. Should the file ever change, you need only alter/re-compile your I/O module - the Subset and all the report programs are unaffected. 

If using this technique, you should also consider the use of DERIVED instance macros. If you define a single macro to call your I/O module, you can attach this macro to the Derived field. If the situation arose in other Subsets, the same Derived macro would serve your purpose. 

Solution 2 - Create a new logical file, that shares the current access path and has only the field(s) your require, and link this into the Subset instead.

There is no overhead and the only extra work is defining the logical file. The creation of the fields into the Subset is done entirely by the Retrieval map function. It is simple and requires no special effort.


Top of page
9. How do I remove a field from the data dictionary?

Ensure that the field is not referenced by any reports, then select it from the data dictionary and use the delete function key to delete the field. If you are not sure whether a field is used in reports, you can determine this by examining the output of the supplied management report: "MAN_RPTFLD".


Top of page
10. Can I delete unwanted database fields from the dictionary?

Fields from your Subset defined database files should not be removed from the data dictionary as this may lead to report compilation problems. If you wish to "hide" them from your users, then you should do this by use of the "User views" feature and/or security not by deleting them from the data dictionary. If you wish to ensure that your users cannot use such fields, then use the "Housekeep - Authorities" function to secure them. 

Fields that have been removed from database files should be removed from the data dictionary. There is no problem in deleting derived (or virtual) fields that are no longer required provided that there are no other fields or logic dependent on those fields. (Home)Top of page footspace.gif (46 bytes) Copyright Momentum Utilities Pty Ltd - July 2016
Legal Information - Privacy - Contact Us