From: | david(at)gardnerit(dot)net |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | schema migration |
Date: | 2009-05-29 21:32:31 |
Message-ID: | 20090529213231.GC6471@monster |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
I am currently in the process of refactoring my database schema.
As part of that I am changing the primary key on one of my tables.
The first thing I did was place a unique contraint on the column I want
to be the new pk, then for each table with a foriegn key I added a new
colum, populated that column, then replaced the foriegn key.
Then I dropped the old primary key from the original table, then created
the new primary key.
The question is, I would like to drop the now redundant unique contraint, but all of the foriegn keys are now dependent on the unique constraint, not the primary key.
I guess the big question is, is this even important? Is there a
performance penalty here?
I'm doing the work on my development machine, not my production server
so I have the option of trying things another way.
From | Date | Subject | |
---|---|---|---|
Next Message | Mohlomi Moloi | 2009-06-02 07:41:03 | DatabaseMetaData |
Previous Message | Richard Broersma | 2009-05-29 20:44:41 | Re: Implementing time constraints |