Re: PK or not PK

In addition to the comments you have already received, having a PK now may save you grief later for other reasons.

Say you want to replicate that data at 5 minute intervals sometime in the future. Guess what you'll need? Yeah, a primary key.

Jared

On Wednesday 07 May 2003 12:07, John Carlson wrote:
> 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: Jared Still
  INET: jkstill_at_cybcon.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).