Re: 1 foreign key to 2 different tables?

On Sun, May 02, 2004 at 03:51:44 -0400,
Ryan Riehle <rkr(at)buildways(dot)com> wrote:
> Thanks for your input. Yes, there is a lot more to this part of the schema.
> The current stucture makes the most sense to us so far, after lots of
> thinking. If you are interested I can offer you more details about the
> structure, but for now I am looking for how to implement this type of
> constraint with a trigger or another method - if there is a better way.

So far I haven't seen a good case for why there needs to only be one
pointer instead of two. When you are doing joins you are going to know
which one you want to join on. They are internal keys so you shouldn't
need to print them out directly. If you want to display something that
comes out of one joined table or the other, you are going to have to
join both a and b to c using some sort of outer joins. You can use
coalesce to get the information form the appropiate joined table.
You will still have to do things like this even if you share the pointer
field c, but it will be easier to set up the constraints if there are
two separate fields.