Transaction Strategies for Natural Primary Keys & Cascading Updates
For those experienced using natural primary key designs, what update
strategies do you use when updating related tuples within a
transaction when the primary key is also subject to changes?
For example consider a table is vertically partitioned into two or
more segments (all related on the natural primary key). Allowing for
the primary key to be updated (and cascaded to the foreign keys), are
there any ways to updated all of the tuples in a single transaction
using the primary key in the where clause?
--
Regards,
Richard Broersma Jr.
Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug
Richard Broersma wrote:
For those experienced using natural primary key designs, what update
strategies do you use when updating related tuples within a
transaction when the primary key is also subject to changes?For example consider a table is vertically partitioned into two or
more segments (all related on the natural primary key). Allowing for
the primary key to be updated (and cascaded to the foreign keys), are
there any ways to updated all of the tuples in a single transaction
using the primary key in the where clause?--
Regards,
Richard Broersma Jr.Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Perhaps table inheritance with OIDS (if I understand the concept of vertical
partitioning correctly)? I'm an amateur at database design, but thought I'd
offer something.
--
View this message in context: http://www.nabble.com/Transaction-Strategies-for-Natural-Primary-Keys---Cascading-Updates-tp25355262p25355755.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.