Thread: self referencing table structure and constraints
I have a categories table that contains a FK to another category in the same table, creating a hierarchy. At the very top is this row: category_id | name | description | parent_id -------------+------+-------------------------+----------- 1 | ROOT | The top level category. | 0 There is no record with category_id 0 because ROOT is at the top of the tree. I'd like to set up a constraint on this table so that every category has to have a parent_id and it would be impossible to delete a category if it had subcategories. The problem is that this root category violates that constraint. Is there a way to setup the constraint so that it constrains every record except for forcing the root category to point at a real parent category? I thought of pointing ROOT to itself, but since we have some recursive code that starts at a given category id and moves up the tree it will hit the ROOT category and loop forever. I'd like to fix this by constraining the database so that even working from psql it would be difficult to damage this table by hand. Are there any widely used techniques for dealing with this type of constraint? Thanks, -M@
On Thu, 23 Sep 2004, Matthew Hixson wrote: > I have a categories table that contains a FK to another category in the > same table, creating a hierarchy. At the very top is this row: > > category_id | name | description | parent_id > -------------+------+-------------------------+----------- > 1 | ROOT | The top level category. | 0 > > There is no record with category_id 0 because ROOT is at the top of the > tree. I'd like to set up a constraint on this table so that every > category has to have a parent_id and it would be impossible to delete a > category if it had subcategories. The problem is that this root > category violates that constraint. Is there a way to setup the > constraint so that it constrains every record except for forcing the > root category to point at a real parent category? Well, to simply have the root category not error, you could use NULL for the parent_id if you're using a foreign key. However, it sounds like your full problem is more complicated. If you want to force that there always exists exactly 1 such row, it's harder. Forcing that there's no more than 1 should be possible without writing triggers (maybe a unique index on ((1)) where parent_id is null) but I'm not sure how else to guarantee that there's at least 1 besides a trigger. > I thought of pointing ROOT to itself, but since we have some > recursive code that starts at a given category id and moves up the tree > it will hit the ROOT category and loop forever. I'd like to fix this > by constraining the database so that even working from psql it would be > difficult to damage this table by hand. Well, in that case you also may need to watch out for cycles. You can do this with triggers, but handling concurrent changes might get tricky.
On Sep 23, 2004, at 6:36 PM, Stephan Szabo wrote: > > On Thu, 23 Sep 2004, Matthew Hixson wrote: > >> I have a categories table that contains a FK to another category in >> the >> same table, creating a hierarchy. At the very top is this row: >> >> category_id | name | description | parent_id >> -------------+------+-------------------------+----------- >> 1 | ROOT | The top level category. | 0 > >> >> There is no record with category_id 0 because ROOT is at the top of >> the >> tree. I'd like to set up a constraint on this table so that every >> category has to have a parent_id and it would be impossible to delete >> a >> category if it had subcategories. The problem is that this root >> category violates that constraint. Is there a way to setup the >> constraint so that it constrains every record except for forcing the >> root category to point at a real parent category? > > Well, to simply have the root category not error, you could use NULL > for > the parent_id if you're using a foreign key. Okay, now I just feel silly. For some reason I was thinking that the parent id couldn't be NULL either. Thanks, this is exactly what I needed. -M@