Index sequential sets and automatic subsets should be used rather than links and manual subsets. This is because links and manual subsets must be assigned programmatically, whereas sets and automatic subsets are maintained automatically by the Enterprise Database Server. In addition, the index sequential type always provides an ordering automatically, whereas any ordering using links must be maintained programmatically. Furthermore, there are usually fewer calls on data management operations in the user application programs. Finally, the greater efficiency of links over sets and automatic subsets is often more perceived than real.

These points can be illustrated by considering the product structure database discussed previously. An implementation of it using embedded manual subsets has already been discussed under the heading “Disjoint Versus Embedded Structures.” Therefore, consider an implementation of the product structure using links. There are two links in the PARTS data set: STARTPLLINK refers to the first one-level-down parts list record in the PARTSLIST data set, and STARTWULINK refers to the first record in the PARTSLIST data set for the one-level-up where-used list of the part.

There are four links in the PARTSLIST data set. Two of these are links back to the PARTS data set: COMPARTLINK links back to the composite part of the PARTSLIST record, and SUBPARTLINK links back to the subpart of the PARTSLIST record. The remaining two links in the PARTSLIST record refer to the PARTSLIST data set itself: NEXTPLLINK links to the next record in the PARTSLIST data set in the one-level-down list of parts of the composite part of the PARTSLIST record, and NEXTWULINK links to the next PARTSLIST data set record for the one-level-up where-used list of the subpart of the PARTSLIST record. This gives rise to the following DASDL description:

PARTS RANDOM DATA SET
 (
  PARTNUM        NUMBER(8);
  STARTPLLINK    IS IN PARTSLIST COUNTED;
  STARTWULINK    IS IN PARTSLIST COUNTED;
  REFCOUNT       COUNT(1000);
       .
       .
 );
 PARTSKEY ACCESS TO PARTS KEY PARTNUM MODULUS 1500;
PARTSLIST DATA SET
 (
  COMPARTNUM     NUMBER(8);
  SUBPARTNUM     NUMBER(8);
  COMPARTLINK    IS IN PARTS COUNTED;
  SUBPARTLINK    IS IN PARTS COUNTED;
  NEXTPLLINK     IS IN PARTSLIST COUNTED;
  NEXTWULINK     IS IN PARTSLIST COUNTED;
  REFCOUNT       COUNT(1000);
     .
     .
 );

To add (or delete) a new PARTSLIST record for part X, a new PARTSLIST record must be inserted (or deleted) in the one-level-down parts list chain for X. The new PARTSLIST record must also be inserted (or deleted) in the one-level-up where-used list for part Y, where Y is the subpart specified in the PARTSLIST record. Since it is desirable to keep the parts list and where-used chains in order of item number and in reverse BLDLEVOUT order within item number order, the existing chains have to be followed and the new record inserted at the appropriate point. The existing links in the chain at that point have to be reassigned to point to the new PARTSLIST record.

As an exercise, you could attempt to sketch the record link relationships and then contrast all the application program code required with the create and store (or lock and store, or delete) operation when the relationship data set technique shown previously is used. It should be easy to see that there are both programming and conceptual advantages to using automatic sets instead of links in this situation.

Note that the index-sequential technique can be thought of as factoring links out of the data records, imposing a logical ordering on them, and maintaining them automatically.

Explosions and implosions using the links could be less efficient than the relationship data set technique. One reason is that an implementation using embedded subsets would be slower—the current record has to be reestablished after each retrieval to use its link to find the next record.

A product structure database in the Enterprise Database Server using the relationship data set technique has been compared against the previously existing hand‑coded product structure module. The hand‑coded version has basically the same logical structure as the implementation just suggested using Enterprise Database Server links. It uses record addresses instead of Enterprise Database Server links. Full-level explosions and implosions are done with the same data, which is a production database consisting of approximately 25,000 parts, 160,000 parts list records, and 8,000 operation records. The Enterprise Database Server version runs significantly faster, although it uses larger blocks, more buffers, and more disk space.