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