multiple target tables for a foreign key?

I'd like to be able to use a foreign key for a defined set
of tables. Any suggestions on how to do this and maintain
some semblance of (DB support for) referential integrity?

Let's say that a key is supposed to point to a "mode of
conveyance" and that the possibilities include cars,
trucks, planes, etc. FWIW, there's no guarantee that the
targets are linked (much) by inheritance, let alone that
STI would be applicable.


Research polymorphic associations. It may be what you need.

Thanks; I'll look into it!


Ignoring the Active Record side of things for the moment, I'd
like to see if I understand the database side of polymorphic
associations. How's this?

  In a linkage table where polymorphic associations are being
  used, each foreign key's id is qualified by a corresponding
  type field. Both the id and the type have to match before
  a join will succeed.

As one of the referenced postings mentioned, this does not do
much to ensure referential integrity. Nonetheless, if correct
SQL statements are used (either directly or via Active Record),
correct results should be obtained.


From what I understand referential integrity is maintained as long as

you define the associations correctly (whether you use simple,
standard has_many/belongs_to associations or more complex polymorphic
associations via belongs_to/has_one as:) AND you use the rails
mechanisms for creating and saving AR objects that those associations

So as an example

a = # has_one referencing_object as:
b = (...) # belongs_to foreign_key :polymorphic
=> true
b.foreign_key = a # foreign_key_id and foreign_key_type automatically
set! # saves both a and b automatically

Rails does not stop you from manually setting your foreign key values
explicitly (b.foreign_key_id = 1;), but referential integrity is not
maintained in those cases. That's part of it's power and
flexibility. But if you can guarantee the data you put in to be
correct, "correct results should be obtained". As a sanity check, you
can always create foreign key constraints in the database (via
migrations of course --- it's the new toy I found) Dave Thomas (of
Agile Web Development fame) recommends doing it.

Lastly, the value of the :dependent option for your associations will
determine how to handle the child(ren) when the parent object is
destroyed (the has_xxx side of the association).

So hopefully that clears things a bit but it probably gave you even
more to chew on. :slight_smile: The web resources are enough to get you going with
Rails but Agile Web Development really helps bring things into focus.
Just to give you an idea, I've been reading the book for the last 3
nights, but been toying with Rails for the last 3 weeks. I learned
enough to be dangerous, but AGW explains not just the what or the how
but delves into the why and does it within a unified context rather
than learning rails from disparate tidbits. :slight_smile: