×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 13-Jun-2017 05:49 -0600, Glenn Gundermann wrote:
I saw some code last night that made me wonder.
One registration table had two unique keys:
The first unique key: (profile, event)
The second unique key: (event, profile)
Whether the Access Paths (ACCPTH) are implemented via Logical Files,
Physical File key, Primary Constraint, Unique Constraint, may be
relevant with regard to other considerations; e.g. a Foreign Key
Constraint can not depend on a LF unique keyed AccPth, so an identical
key [order mattering] for a parent would need to exist on the TABLE.
I'm wondering if it's redundant to have the second unique key since
the first unique key will ensure this.
From that specific perspective, indeed, the additional key is
redundant; i.e. either unique key definition, alone, will prevent
duplicate key values across those two columns.
For performance, it makes sense to have an index for (event,
profile). Is there any extra overhead or inefficiency by making
it a unique key?
Clearly, there is a penalty for maintenance; per the existence of the
second access path, because the Maintenance (MAINT) attribute can only
be set to *IMMED.
But, there may be, even if obscure, reason(s) for the existence,
beyond what is necessarily redundant for maintaining uniqueness;
constraints, reorganize physical file (RGZPFM) data, Open Query File
(OPNQRYF) via Classic Query Engine (CQE), RLA ISAM [as in, RPG with
F-Spec to named/overridden-to file expected to have Unique attribute],
etc. So, in other words, changing the AccPth to no longer be unique,
due solely to that originally noted apparent redundancy, could prove
problematic.
midrange.com
