Question

There are several types of objects in a system, and each has it’s own table in the database. A user should be able to comment on any of them. How would you design the comments table(s)? I can think of a few options:

1. One comments table, with a FK column for each object type (ObjectAID, ObjectBID, etc)
2. Several comments tables, one for each object type (ObjectAComments, ObjectBComments, etc)
3. One generic FK (ParentObjectID) with another column to indicate the type (‘ObjectA’)

Which would you choose? Is there a better method I’m not thinking of?

Answer 1

@palmsey

Pretty much, but the variation on that pattern that I’ve seen most often gets rid of ObjectAID et al. ParentID becomes both the PK and the FK to Parents. That gets you something like:

• Parents

  • ParentID

• ObjectA

  • ParentID (FK and PK)
  • ColumnFromA NOT NULL

• ObjectB

  • ParentID (FK and PK)
  • ColumnFromB NOT NULL

Comments would remain the same. Then you just need to constrain ID generation so that you don’t accidentally wind up with an ObjectA row and an ObjectB row that both point to the same Parents row; the easiest way to do that is to use the same sequence (or whatever) that you’re using for Parents for ObjectA and ObjectB.

You also see a lot of schemas with something like:

• Parents
  • ID
  • SubclassDiscriminator
  • ColumnFromA (nullable)
  • ColumnFromB (nullable)

and Comments would remain unchanged. But now you can’t enforce all of your business constraints (the subclasses’ properties are all nullable) without writing triggers or doing it at a different layer.