Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: PK or not PK

Re: PK or not PK

From: Ron Rogers <RROGERS_at_galottery.org>
Date: Wed, 07 May 2003 12:24:05 -0800
Message-ID: <F001.00593050.20030507122405@fatcity.com>


John,
 If the child table has a primary key will it also be unique?? A pk/unique column on the child will pervent duplicates and is that something that you want to happen. I do not know what your data looks like but mom has two children, son and daughter. If the son and daughter are pk/unique then there can not be any more son's or daughter's in the table.
 I do not find the relationship between not being able to handle Oracle ROWID and a PK. A Rowid is a multi character value depending on the Oracle version. A PK is an index on a column for speed and uniqueness. If they write the code for Oracle 7 rowid it might not work for Oracle 8 rowid as the format is different.
Ron  

>>> jcarlson_at_cj.com 05/07/03 03:07PM >>>
I am searching for arguments for NOT having a primary key. All I seem to find are discussions about how to use artificial or surrogate keys but nothing about not needing them at all.

For example, a one to many relationship. Parent table has a primary key but the child table does not have any natural unique key. You create a foreign key with a non-unique index on the child table and that is all you really need. Now, the application queries the parent child relationship and lists rows for a given parent. The user then selects one of the rows and the program needs to select that record for update. This can easily be accomplished with rowid; however, our developers use a tool which ( in an effort to be a generic tool ) cannot handle oracle's rowid and insists on having a primary key on the child table.

My argument is that this is a total waste of resources. It takes overhead to maintain an index and it also consumes disk space and serves no useful purpose. Their argument is that they want their code to be independent of the database so we could switch from oracle to any other database without changing any code. I say that is ridiculous because you always have to 'tune' your code to work efficiently and each one has their own unique requirements. Another argument is that in a true relational database, all tables must have a primary key. I don't know anyone who has a 'true' relational database just like you are supposed to use third normal form. But, in order to help queries be more efficient, we often back off to second normal form. It just isn't realistic or practical in the real world to conform to all the 'rules'.

Can anyone help me out or am I fighting a loosing battle?

TIA,
John Carlson
www.cj.com
Santa Barbara, CA. USA

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net 
-- 
Author: John Carlson
  INET: jcarlson_at_cj.com 

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com 
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Ron Rogers
  INET: RROGERS_at_galottery.org

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Wed May 07 2003 - 15:24:05 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US