I would go the other way; I'd add a unique constraint to L10NCODE and
leave the ID field in as the primary key. I think it's a bad idea to
use anything in your data as a primary key because I worry that you can
never be absolutely sure that you won't need to change that data. To
me, the only safe primary key is a synthetic primary key, only because
it's probably safer in the long run.
Ricardo Palomares wrote:
Thomas Dudziak escribió:
Think of it this way: the primary key sort-of defines the identity of
the row. So, if L10NCODE uniquely defines a row in the table (and thus
could be used for primary key), then all you have to ask yourself is:
does it make sense in your application to have L10NCODE be the primary
key ? This is not so much a database question but a application design
question. Imagine that you have multiple unique columns in the table,
which one would you choose for the primary key (if any) ?
Definitely, I'll remove the ID field. The actual reason I added these
"sintetic" ID fields is because I've read so much about the goodness
of using them, instead of the otherwise natural PKs, to speed up
databases, that I bit the bullet and ended declaring them for every
table as a sign of a well designed database. Novice sins, I guess.
Thank you very much for your time.
Ricardo
--
Rusty Wright
UC Berkeley
IS&T Web Applications
510-643-9097 office
925-212-3774 cell
