On Sunday 11 September 2005 16:04, Greg Sabino Mullane wrote: > Not just old-fashioned, it's the biological law! (among homo sapiens > anyway). I'd approach this with a trigger, as you can do complex > checks and get back nice customized error messages. A sample script > follows. Hard to tell without seeing your whole schema, but I see no > need for a relation_id primary key if you already have a unique > constraint on child_fk and parent_fk, so I made those into the > primary key for the relations table:
Thank you for an excellent answer. I think I will have to study your code for a while. But is it such a bad idea to have a separate column for the primary key here? I see that there are two schools on this, with diametrically opposed views. For my own part, I feel that it at least doesn't hurt to have a surrogate key. Secondly, a single key value is easier to reference from another table than a composite key. -- Leif Biberg Kristensen http://solumslekt.org/ ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
