RE: PK's enforced via constraint or unique indexes?

PK's are your way of telling the system (and other programmers) what the
true unique key is to a file. As a general rule, primary keys don't
change. That isn't to say they can't, but rather, that they shouldn't.
Many 3rd party tools will assume/require that you have a PK defined on a
table. Defining a PK also defines the path FKs will take to validate
their data. I would recommend, as good DB practice, always defining PKs
on a file. 

I can't see why an optimizer would favor a PK over any other index, but
hey, I don't write optimizers. Optimizers are tricky things, that take
all sorts of machine conditions into consideration, and aren't really
meant to be understood. I know, for example, that DB2/400's sql engine
will limit the amount of memory it uses to the size of the pool divided
by the maxact of the pool. I can imagine a case w/an optimizer where it
would determine that if nothing was in memory then index A would be the
best approach, but since index B is already in memory, even though it's
less-optimal in theory it's better since it would result in fewer IOs.

In your case, I'd leave the PK and question the need for the unique
index.

-Walden