Re: Primary Keys optional?

From a practical standpoint, you absolutely require a PK (or some
set/combinations of columns that uniquely identifies a row) when you'll be
replicating from one database to another.  Because replication, regardless of
what mechanism is used, simply doesn't work without a way to uniquely identify
a row -- no way, no how, just can't be done.

And since nobody can ever anticipate whether something will be replicated in
future (probable exception of "scratch" or "temp" tables), it is irresponsible
not to design a PK from the get-go.



On Thu, 17 Aug 2006 09:46:36 -0700, Stephen Andert wrote
> OK, just starting a new job with more design than I have done in a
> while.  Looking into things, I have been noticing that many tables
> have no PK.  Some have a unique index, but not all.
> 
> When I pointed this out to folks (developers) they shrugged and said
> "if you need a PK, then create one".
> 
> So my questions are:
> 
> 1. Is it considered acceptable to have a unique index instead of a pk?
> 
> 2. What are the circumstances when a table might be allowed to exist
> without any sort of primary key or unique index?  (i.e. temp table,
> static small table, etc)
--
http://www.freelists.org/webpage/oracle-l

Other related posts: