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.

-r

Research polymorphic associations. It may be what you need.

http://wiki.rubyonrails.org/rails/pages/PolymorphicAssociations

Thanks; I'll look into it!

-r

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.

-r

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 provide.

So as an example

a = ReferencedObject.new(...) # has_one referencing_object as: foreign_key b = ReferencingObject.new (...) # belongs_to foreign_key :polymorphic => true b.foreign_key = a # foreign_key_id and foreign_key_type automatically set b.save! # 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: