In most cases, the answer is yes. The most common reason for apparently identical fields to exist in a Subset is where the field is a key in one or more files. For example, customer number might be a field in the order header, but it is also the key to the customer master file. Consequently, there are two fields defined in the Subset called customer number, and the choice of which field to use can be significant.

Consider a report that lists some fields from the order header file. No customer details are required, only the customer number. If the customer number from the customer master is chosen instead of the customer number from the order header, then OPEN/DB thinks that the customer master file is required and will include it in the report - normally, it would be omitted.

Note that this problem is not functional - whichever customer number is used, the resulting report will be correct. However, there may be an effect on relative performance.

Most of the factors affecting performance, at least in Subset design, are connected with the definition of one-to-many relationships or the use of OPNQRYF. 

The main performance-related factor in the definition of one-to-one relationships is the choice of parameters controlling OPEN/DB's use of "in-core" logic. Choosing in-core logic instructs OPEN/DB to generate code that will retain the last n used records in program variables, and retrieve the required record from the program variables if possible. By default, this option is selected for every one-to-one relationship that you define, and the default value of n is 20. 

In the majority of cases, this option considerably speeds up data retrieval by reducing the disk I/O that a report needs to perform. In most cases, it will be sufficient to accept the defaults that OPEN/DB proposes. Only in a couple of situations might you wish to vary from the defaults, and you should consider carefully before doing so to ensure that your changes will have the desired effect:

• There may be some cases where the nature of the relationship and of the data means that the chances of scoring a "hit" using the in-core logic are extremely small. In these cases, you may wish to turn the option off and eliminate the overhead of having OPEN/DB search its 20 last-used records before performing the I/O. This benefit is likely to be marginal in most cases, since the search is a high speed CPU-bound process. The potential performance loss of turning it off inappropriately is likely to be much larger. Therefore, you should be very sure that your reasoning is sound before taking this action.
• More commonly, you may wish to fine-tune the value of n to suit particular situations. For example, if your company only sells 25 products or services, then you may wish to alter the value for a link to your product master file to say 30 (allowing for a little growth in your product range). By doing this, you can be sure that OPEN/DB will only ever read each product master file record once for an entire report run.

You should not increase the value of n to excessive levels. There will come a point, probably somewhere around 200-300, when it takes longer for OPEN/DB to search the retained records than it would have taken to perform the I/O, and the benefit will have been lost.