× 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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.