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


  1.  Home
  2. MIDRANGE-L
  3. March 2009

RE: To Key or Not To Key a Physical

I would agree that every table should have a unique key. Isn't the question if that key should be defined by keying the physical file? There I would say no. Create a logical file over the physical that has the unique key definition. Makes future maintenance easier when the primary key changes for the table or you might need to do something to the table that would violate the unique key temporarily. In that case you just delete the logical file, do what you need to do and recreate the logical.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Thursday, March 26, 2009 3:44 PM
To: Midrange Systems Technical Discussion
Subject: Re: To Key or Not To Key a Physical

I think you are missing the point. There should always be an primary index
on every file that uniquely identify every attribute. The question is what
key uniquely identifies each attribute. It is not just an index.

Any other index that you add are just for access or performance reasons.

For example, if you have a Order file. The primary key should be the order
number but it might be the company and order number but no matter what every
field in the table (attribute) should be uniquely defined by the key.

That primary index should always be a unique key.

On Thu, Mar 26, 2009 at 12:41 PM, Kurt Anderson <
kurt.anderson@xxxxxxxxxxxxxx> wrote:

I tried looking online for more information about how indexing occurs and
couldn't pinpoint it.

Maybe an example will help.
I want two keys over a file:
Key1: FieldA, FieldB
Key2: FieldB, FieldA

Option 1 is to have an arrival sequence Physical and 2 Logicals.
Option 2 is to key the Physical (let's say Key1) and then make a Logical,
Key2.

I've always preferred Option 2 for the simple reason of: hey, 2 files
instead of 3; however I've been approached with the thought that Option2
will index over an index which would be less preferable to indexing over a
non-keyed Physical. Is this a valid concern?

Charles, you say that it's the general standard to always key the Physical.
I guess I'm looking for the reasoning behind that.

Thanks,
Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Thursday, March 26, 2009 1:21 PM
To: Midrange Systems Technical Discussion
Subject: Re: To Key or Not To Key a Physical

Huh?

If you create a logical with the same access path as the physical, the
logical will share the PF access path.

Now-a-days, the recomendation is to always define a primary (aka
unique, non-NULL) key for the physical.

Charles

On Thu, Mar 26, 2009 at 2:13 PM, Kurt Anderson
<kurt.anderson@xxxxxxxxxxxxxx> wrote:
If I'm going to have multiple logical files over a physical file, is it
better to not key the physical file or is there no implication if I do key
the physical file (and reduce the number of logicals needed by 1)?

I'm not that familiar with how indexing works, and the concern is that a
logical over a keyed physical will be indexing from an index.

Thoughts?

Thanks,

Kurt Anderson
Sr. Programmer/Analyst
CustomCall Data Systems
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
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.