Re: Inserting a new PK into an existing table
- From: "Jens Lenge" <spampot@xxxxxxx>
- Date: 31 Aug 2006 09:28:50 -0700
Mark D Powell wrote:
Normally we use a business column or set of column values in the table
to be the PK and do not use an artificial key since if a unique
business value exists there is no need for or real use of an artificial
key.
In general, I would agree. In this specific case however, I think it
could be desirable to have an additional primary key column because:
a) The "old" primary key is composed of multiple columns (whose
specific combinations remain unique, which will still be enforced by a
unique constraint).
b) Unlike before, the table is now going to be referenced by several
other tables via foreign keys. Without the new artificial primary key,
this would require multiple new columns in all of these tables (along
with a foreign key that is composed of these columns).
I thought the new primary key would be a good idea to reduce redundancy
and simplify the structure, because now I only need to add one new
column to each of the other tables. Or is it better to use a different
approach?
You can populate a numeric column with unique values by performing an
update statement that references the rownum for each row in the table.
[...]
Perfect solution. Thank you!
Jens
.
- Follow-Ups:
- Re: Inserting a new PK into an existing table
- From: Ed Prochak
- Re: Inserting a new PK into an existing table
- References:
- Inserting a new PK into an existing table
- From: Jens Lenge
- Re: Inserting a new PK into an existing table
- From: Mark D Powell
- Inserting a new PK into an existing table
- Prev by Date: Re: Inserting a new PK into an existing table
- Next by Date: Re: what's wrong with my package? (not a personal problem)
- Previous by thread: Re: Inserting a new PK into an existing table
- Next by thread: Re: Inserting a new PK into an existing table
- Index(es):
Relevant Pages
|