RE: PK or not PK

Hi John,

My 2 cents:

1. Without a natural primary key or at least a unique constraint, how do you prevent duplicates? Don't tell me that the code won't allow dupes. Been there and barely survived that.
2. Someone deletes a bunch of records. Damagement asks "Can't you just import the missing records from last Friday's export without messing up the new data we entered since then?" Not without a primary key or unique constraint.

I'm on a database where less than 20 percent of the tables have a primary key or unique constraint. It is truly sad what happens. Duplicate records abound which mess up reports frequently. I've instituted a rule that any new tables or tables undergoing a major redesign now require a primary key.

Jerry Whittle

> -----Original Message-----
> From: John Carlson [SMTP:jcarlson_at_cj.com]
>
> 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: Whittle Jerome Contr NCI
  INET: Jerome.Whittle_at_scott.af.mil

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