RE: PK or not PK

If your developers are insisting on PK's, I say bless 'em. My rule is that every table has a primary key. My experience has been, if a table does not have a primary key, then it gets duplicate rows. Duplicate rows are bad.

Features of relational databases that enforce data integrity are not a waste of resources. They are the features that make the database relational.

> -----Original Message-----
> From: John Carlson [mailto:jcarlson_at_cj.com]
> Sent: Wednesday, May 07, 2003 3:07 PM
> To: Multiple recipients of list ORACLE-L
> Subject: PK or not PK
>
>
> 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).
>
>

LEGAL NOTICE:
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Sarnowski, Chris
  INET: csarnows_at_CuraGen.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).