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